Hi Stefan,
i am using the svn log command with a "forward" revision range, e.g. "-r
N:HEAD".
This fails if the requested path has been deleted in HEAD revision.
When used with "backward" ranges, which are commonly used, e.g. "-r N:1", the
result is ok - even if the requested path is not present in revision 1.
I do understand the implications of going "forward" through the history.
But would it be possible to modify the svn log command to be improved for these
cases?
If such an implementation would require more computations it could be used as a
fallback only if the resource does not more exist in HEAD (resp. in the
end-revision).
What kind of enhancement do you have in mind? Specifically, which
feature is missing that Subversion doesn't already have?
The following command will fail, if the given resource has been deleted in a
revision higher than N:
svn log -r N:HEAD file:///repository-and-path-to-resource
It would be very useful if this would work the same as when used with backward
ranges (e.g. N:1).
An example use case would be that a user wants to browse to a more recent
revision of a resource.
Without this enhancement the user must repeat the command over and over with "-r N:N+1",
"-r N:N+2" until the command fails.
This is a known problem:
http://subversion.tigris.org/issues/show_bug.cgi?id=2873
It has nothing to do with the direction of history traversal though.
It also happens during backwards traversal.
I doubt that this is an exact duplicate of the mentioned svn diff issue (but
may be the source is the same - i don't how it works internally).
For the svn log command the direction "-r N:1" works fine - even if the
resource does NOT exist in revision one.
So in this case the resource is NOT checked to exist in both start and end
revision.
For the forward case the existance in the end revision seems to be checked
indeed.
This is what should be improved to enable the usage of "-r N:HEAD" even for
later deleted items.
Dirk
