On 11/30/2010 7:39 AM, Andrey Repin wrote:
> Greetings, Les Mikesell!
>
>>> Still, this should at least produce some results: (as long as foo existed
>>> in rev 3)
>>> svn log -r 0:head file://${HOME}/trash/repo/foo_at_3
>>> svn: File not found: revision 5, path '/foo'
>>> It makes no sense for svn to complain about what's in rev 5. My query
>>> doesn't care about rev 5.
>
>> I think the principle was covered in another response, but the only way
>> you can get history is to start from the highest rev and follow
>> backwards, and you are asking it to start from head, which is impossible.
>
> Impossible within current realization of storage backend. But sensible from
> user's viewpoint and scheduled to be resolved in future.
> I'd ask you to stop giving out your own opinion under mask of absolute truth.
I'm admittedly not an expert, but I don't understand exactly how this
can be resolved to work the way you want when the names of objects are
only loosely connected to the objects themselves. That is, a path and
revision in peg revision form uniquely identifies an object, and that
object has a certain amount of history. However that same path at any
other revision may be an entirely different object with a different
history or may not exist at all. If subversion starts to track the
'copy-to' info so you can follow revisions in the forward direction, you
can end up with many different descendants with different paths, but
it's not clear that would make it any easier to find the dead ends of
deletions.
I can see that subversion could, with some extra work on the server
side, track down the end of the line in the future of foo_at_3 by examining
every subsequent revision when you ask for:
svn log -r 0:head file://${HOME}/trash/repo/foo_at_3
But what should it do if a different object with the same name but a
different history has been copied into head where you are really asking
it to start giving history?
Also, when you copy a directory in subversion, you expect it to bring
along all of the history of that directory and the objects under it. If
you want it to remember that a deleted object once lived under a certain
path, when that path is copied, would you also want it to think that the
deleted object was once under this new copied path?
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-30 17:58:29 CET