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

Re: Join 3 Files with History?

From: Zing <zing+svnusers_at_fastmail.fm>
Date: Tue, 18 Aug 2009 14:27:16 -0400 (EDT)

On Mon, 17 Aug 2009, Ryan Schmidt wrote:

> On Aug 17, 2009, at 14:51, Jan Hendrik wrote:
> > Ryan Schmidt wrote on 16 Aug 2009, 14:20, at least in part:
> >
> >> Peg revisions are not special or super revisions. They are your
> >> regular and ordinary revisions. There are just two ways of having
> >> Subversion use them: the usual way is called operative revisions and
> >> has the syntax "-r OPREV". The peg revision syntax is "@PEGREV" at
> >> the end of a URL. Consider:
> >>
> >> svn cat -r OPREV url://to/file_at_PEGREV
> >>
> >> It means: Go to revision PEGREV in the repository and get the object
> >> known at that time as "file". Then display revision OPREV of that
> >> object. This is useful if "file" was deleted at some point, then
> >> recreated anew later or copied from an entirely different object. The
> >> peg revision allows you to specify that you want the older object by
> >> the same name, not the object by that name that's currently there.
> >
> > I assume that OPREV has to be smaller than PEGREV and would
> > display the file content.php_at_100 as it looked like in rev. 35 when it
> > probably even was named draft49.php still.
> As far as I know, there is no reason why the OPREV would need to be
> smaller than the PEGREV. Perhaps you know that file.txt existed in
> directory foo in revision 600 and has been moved and renamed since then
> and you would like to see the current version of that file, wherever it
> is. You could say
> svn cat url://to/file.txt_at_600 -rHEAD
> which should go to revision 600, locate the object that was called
> file.txt at that time, then follow it through history up to revision
> HEAD, and show its contents in that revision.

Subversion has a kind of half-hearted attempt at supporting an OPREV >
PEGREV. It's tough to fully support, because if a bunch of copies and
renames have happened, which branch do you follow as you go forward in

As it is now, 'svn log' is even less capable than 'svn cat', it will spit
out the history of an object not even related to the PEGREV'd file...
that's probably a bug, and I think it's been mentioned before on this

Anyway, it may be best to just generally recommend that people not do
OPREV > PEGREV calls. For simple repos where not a lot copies or renames
have happened (read: none), it'll probably do what you expect, else watch


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-18 20:28:15 CEST

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

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