You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2010/03/05 17:52:53 UTC
Peg revision question
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/java/javahl/src/org/tigris/subversion/javahl/NotifyAction.java@850567
I have given SVN a known URL@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/
Re: Peg revision question
Posted by Peter Samuelson <pe...@p12n.org>.
[Johan Corveleyn]
> If I'm not mistaken, exactly the same issue occurs with a simple
> delete (no copies or moves involved). This can be very annoying if
> you're trying to find out in what revision an item was deleted (and
> why (log message) and by which author).
The usual workaround is to get a log -v of its parent directory and
just look for the " D ". And yes, it is annoying (and of course won't
work if the parent was deleted at the same time).
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: Peg revision question
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 5, 2010 at 10:01 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Mark Phippard wrote:
>> Copy is a little different. For that, I would like to be able to
>> specifically ask SVN to do it, which is what you are saying here. If
>> an item is moved, I do not think you should even have to ask.
>
> Agreed.
>
>> If you
>> know a URL/Rev where something existed you ought to be able to just
>> get the entire history of that item, but to do that, I think we would
>> need a first class notion of moving something.
>
> In theory, the repository layer could say "I see that this item was copied
> away and deleted from this path at the same time." In practice, "deleted at
> the same time" isn't as easy to detect as we'd like. (I've been doing some
> thinking in these parts off and on ... toying with the cost/benefit of
> storing an explicit end-of-life marker on a line of history. But I don't
> like where the 'cost' part leads me.)
If I'm not mistaken, exactly the same issue occurs with a simple
delete (no copies or moves involved). This can be very annoying if
you're trying to find out in what revision an item was deleted (and
why (log message) and by which author). Also, you cannot see any other
log entry that happened after the peg revision (except by trial and
error, specifying further rev numbers until you hit a "not found").
Usually people remember some revision in which the item was still
present, but that can be several thousand revisions ago...
Example scenario:
$ cd test
$ svnadmin create repos1
$ mkdir wc1
$ svn mkdir file:///c:/test/repos1/trunk -mtest
Committed revision 1.
$ cd wc1
$ svn co file:///c:/research/testrepos/repos1/trunk .
Checked out revision 1.
$ echo test > superfile.txt
$ svn add superfile.txt
A superfile.txt
$ svn commit -m"adding superfile.txt"
Adding superfile.txt
Transmitting file data .
Committed revision 2.
$ svn rm superfile.txt
D superfile.txt
$ svn commit -m"removing superfile.txt"
Deleting superfile.txt
Committed revision 3.
$ svn log file:///c:/research/testrepos/repos1/trunk/superfile.txt@2
------------------------------------------------------------------------
r2 | User | 2010-03-05 23:05:15 +0100 (vr, 05 mrt 2010) | 1 line
adding superfile.txt
------------------------------------------------------------------------
# Great, but I'm not seeing the log entry in which it was deleted ...
nor any other interesting revisions that happened to superfile.txt
after 2
$ svn log -r 1:HEAD file:///c:/research/testrepos/repos1/trunk/superfile.txt@2
svn: File not found: revision 3, path '/trunk/superfile.txt'
# :-(
Regards,
Johan
Re: Peg revision question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> Copy is a little different. For that, I would like to be able to
> specifically ask SVN to do it, which is what you are saying here. If
> an item is moved, I do not think you should even have to ask.
Agreed.
> If you
> know a URL/Rev where something existed you ought to be able to just
> get the entire history of that item, but to do that, I think we would
> need a first class notion of moving something.
In theory, the repository layer could say "I see that this item was copied
away and deleted from this path at the same time." In practice, "deleted at
the same time" isn't as easy to detect as we'd like. (I've been doing some
thinking in these parts off and on ... toying with the cost/benefit of
storing an explicit end-of-life marker on a line of history. But I don't
like where the 'cost' part leads me.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Peg revision question
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Mar 5, 2010 at 3:49 PM, C. Michael Pilato <cm...@collab.net> wrote:
> I actually *would* expect Subversion, when tracing history from the origin,
> to follow into any and all copies if asked to do so. If you poll our
> customer base, you'll find similar wishlist items, usually of the sort that
> sound like "Show me all copies of some_file so I can port a particular bug
> fix I just made to those places, too."
Agreed. I think I am venturing into the "true renames" territory here
though as well. For me, if you move something then it is still the
same thing and SVN ought to automatically follow the history to the
new location.
Copy is a little different. For that, I would like to be able to
specifically ask SVN to do it, which is what you are saying here. If
an item is moved, I do not think you should even have to ask. If you
know a URL/Rev where something existed you ought to be able to just
get the entire history of that item, but to do that, I think we would
need a first class notion of moving something.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Peg revision question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Fri, Mar 5, 2010 at 1:55 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> It's not a new "line of history" of any sense that we typically sling that
>> phrase.
>
> I guess I was thinking that even though this was moved, internally it
> was a copy + delete. So what if it had just been a copy only? We
> would never expect the history from the origin to follow into the copy
> in that scenario (as opposed to just staying in the origin). So I at
> least think it is a related but new line of history from the point of
> copy?
I think we're just using slightly different terminology here, and for me the
word "new" is the part that's not consistent with the way I've been talking
about lines of history for the past so many years. It's not a big deal
though. Yes, a copy introduces some fork in the existing object's
historical lineage. Whether that's a "new line" or a "fork in the existing
line" is today irrelevant -- your concern is what Subversion can and can't,
should and shouldn't do when navigating such artifacts of history.
I actually *would* expect Subversion, when tracing history from the origin,
to follow into any and all copies if asked to do so. If you poll our
customer base, you'll find similar wishlist items, usually of the sort that
sound like "Show me all copies of some_file so I can port a particular bug
fix I just made to those places, too."
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Peg revision question
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Mar 5, 2010 at 1:55 PM, C. Michael Pilato <cm...@collab.net> wrote:
> It's not a new "line of history" of any sense that we typically sling that
> phrase.
I guess I was thinking that even though this was moved, internally it
was a copy + delete. So what if it had just been a copy only? We
would never expect the history from the origin to follow into the copy
in that scenario (as opposed to just staying in the origin). So I at
least think it is a related but new line of history from the point of
copy?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Peg revision question
Posted by "C. Michael Pilato" <cm...@collab.net>.
It's not a new "line of history" of any sense that we typically sling that
phrase.
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@PEG, that's cool;
otherwise, fail."
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 <st...@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@850567
>>>
>>> I have given SVN a known URL@REV combo where a path existed, why can
>>> it not figure out where it is now and give me the history?
>
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Peg revision question
Posted by Mark Phippard <ma...@gmail.com>.
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 <st...@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@850567
>>
>> I have given SVN a known URL@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/
Re: Peg revision question
Posted by Alexey Neyman <st...@att.net>.
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@850567
>
> I have given SVN a known URL@REV combo where a path existed, why can
> it not figure out where it is now and give me the history?