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@PEG, where Y> PEG, don't croak when PATH@Y > >doesn't exist. Instead, automatically substitute for Y the last revision in > >which PATH@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.
