>>> 1. For 'svn log -rX:Y PATH_at_PEG, where Y> PEG, don't croak when PATH_at_Y
>>> doesn't exist. Instead, automatically substitute for Y the last revision in
>>> which PATH_at_THAT-REV *did* exist, and continue the operation. I believe this
>>> is something that we can reasonably achieve without too much trouble and,
>>> more importantly, in a client-side change (which helps with client/server
>>> compatibility).
>>
>> this feature (1) would be really great.
>> Could you estimate if this is either a very complex feature or rather easy to implement?
>
> I might be mistaken, but I think this is a rather simple change to
> svn_client_log5() in the file libsvn_client/log.c. The variable
> session_opt_rev needs to be bound by the peg revision value.
> It's currently bound by the range specified in the -r argument.
i have filled an issue for this feature - http://subversion.tigris.org/issues/show_bug.cgi?id=3830.
>>> 2. Consider deletion events as "interesting history points" when displaying
>>> the revisions logs for a given path. This is a bit more controversial, as
>>> our revision log display is driven wholly by the DAG structure of the
>>> version filesystem, and a deletion event doesn't leave a trace on the part
>>> of the DAG related to the deleted thing. Deletion is an event which occurs
>>> on the parent directory of the deleted thing only. That said, I recognize
>>> the value in showing *something* to users so that they can tell the
>>> difference between "Nothing new has happened to PATH lately" and "...that's
>>> because PATH has been deleted".
>
> Feel free to file both issues yourself. Make sure to include a link
> to this discussion in the mailing list archives so people can locate
> this discussion easily. Thanks!
>
> BTW, I don't think that solving (2) is realistic at this point.
> But filing an issue about it cannot hurt.
Since i have no direct use case for this in my development, could you - Alan - fill an appropriate issue for this specific feature?
Thank you all for your comments and i am looking forward for this feature
Dirk
Received on 2011-03-09 00:33:59 CET