It's not a new "line of history" of any sense that we typically sling that
But we do lack the forward history searching capability today (due primarily
to failure to track node-revision ancestor-id's), so the best thing our
repository logic can do is "look for something called PATH in HEAD, and if
it's there and is part of the same line of history as PATH_at_PEG, that's cool;
Since in your case the item has been renamed since the PEG revision, the
repository logic just gives up (rather than attempt something obnoxious like
a repos-wide search for the new location).
Mark Phippard wrote:
> Yes, it occurred to me after sending that the new location is really a
> new line of history. There is no guarantee when I moved this that the
> original line stopped (because of copy + delete).
> It works when going backwards because we know where it came from.
> On Fri, Mar 5, 2010 at 1:14 PM, Alexey Neyman <stilor_at_att.net> wrote:
>> I would guess that's because of lack of the "copied-to" information
>> repository. See the discussion of "true renames" - the problem is that
>> Subversion tracks only where the path was copied from, but does not track
>> where it was copied to.
>> Moreover, the path may have been copied to more than one place. I am not
>> sure what would be the expected result from this command in such
>> scenario - list revisions on all paths that have NotifyAction.java as
>> On Friday 05 March 2010 09:52:53 am Mark Phippard wrote:
>>> This is a random example from our own repository. Can someone explain
>>> why a command like this does not work?
>>> $ svn log --limit 5 -rHEAD:0
>>> I have given SVN a known URL_at_REV combo where a path existed, why can
>>> it not figure out where it is now and give me the history?
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-05 19:55:44 CET