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.
>> Peg revisions are also good for examining objects which have been
>> deleted from the HEAD. For example, if in revision 500 you delete
>> content.php but you later want to go back and examine its log, you
>> can
>>
>> svn log url://to/content.php_at_499
>>
>> You specify a peg revision in which the file still existed (so
>> anything between the time the file was created and 499, since in 500
>> it's gone). If you don't specify a peg revision, it defaults to HEAD,
>> so "svn log url://to/content.php" (without a peg revision) won't work
>> if you've deleted content.php from the HEAD.
>
> Honestly, I still don't get it. Of course I understand that svn log
> url://to/content.php won't work if content.php doesn't exist anymore
> in HEAD. Yet why can't I say svn log -r499 url://to/content.php
> when I want to see the log of rev. 499 for a file named content.php
> present in that revision? Or svn log -r400:499 url://to/content.php?
I neglected to mention the defaults. In the yellow box "The Peg
Revision Algorithm" on this page of the book
http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html
it says "the default peg revision is BASE for working copy items and
HEAD for repository URLs. And when no operative revision is provided,
it defaults to being the same revision as the peg revision."
So, your example
svn log -r499 url://to/content.php
is really (because of the default peg revision)
svn log -r499 url://to/content.php_at_HEAD
which won't work, because content.php does not exist in HEAD.
> Maybe because Subversions follows moves/renames? Either way I
> would have to know first that in rev. 499 there still was a file named
> content.php.
Yes, that is a trick, figuring out what revision the file still
existed in. You either have to know it, or find it out by looking
through log messages. If you know content.php was combined with
lecture.php, you can look through the the list of files affected by
the commits to lecture.php (svn log -v url://to/lecture.php) -- There
should be a "D content.php" in there somewhere to tell you what
revision content.php was deleted in. If you don't know content.php
became part of lecture.php, you would have to get the verbose log of
the whole directory where content.php used to live and look for the
same "D content.php" indicator.
> Anyway, this leads off-topic and is of little use in this
> case and at this moment - if I don't understand this, I can't explain
> it to the writers who in turn I suspect cannot even access
> peg_at_revisions at all through Tortoise or what ever they use as GUI.
> Someday I shall give that chapter another read.
I'm not sure what controls TortoiseSVN gives you over this, but they
have documentation of their own, and of course their own mailing list
where you can ask if necessary.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384588
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-18 03:15:35 CEST