On Tue, Mar 08, 2011 at 05:05:10PM +0100, Avalon wrote:
> >There are now two different issues brought up in these thread:
> >
> >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.
> >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".
>
> Even without (2) being implemented any userland code can at least easily distinguish that the resource has been deleted between Y and HEAD, which is already a good information for the user.
>
> Will someone of the dev fill issues for both feature requests?
> I really hope that especially (1) gets implemented rather sooner than later since it is a very crucial feature when walking through the logs.
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.
Received on 2011-03-08 21:16:55 CET