[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Peg revision question

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 5 Mar 2010 13:16:49 -0500

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
> ancestor?
>
> Regards,
> Alexey.
>
> 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
>> https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/j
>>ava/javahl/src/org/tigris/subversion/javahl/NotifyAction.java_at_850567
>>
>> 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?
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-03-05 19:17:23 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.