>>> 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:
> 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.
Received on 2011-03-07 13:30:00 CET