Vincent Lefevre wrote:
> Hi,
>
> The description of the Peg Revision Algorithm on
>
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.pegrevs
>
> is incomplete. It doesn't say how <item> is identified when it is
> relative to a working copy. This is particularly important when
> the directory in question has been renamed/moved in the past and
> PEG-REV is a revision before the rename.
>
> IMHO, it should follow the directory history, but this doesn't seem
> to be what happens.
I think you've missed a key assumption of the peg-rev algorithm. (And
perhaps this is the true failure of my peg-rev description in the book --
I'm willing to accept that possibility.)
The (path, peg-rev) informational pair is really the primary input to the
algorithm, and is expected to represent a point in the history of the object
of interest *that you already know*. This is why Subversion defaults to
using 'BASE' for the peg-rev on working copy operations -- your working copy
reflects paths at revisions that they are known to exist at. It's the
operational revision that you then supply or tweak to operate on some older
version of that thing.
I think you're describing the situation where you have a working copy of,
say, ^/branches/my-branch, copied from ^/trunk in r100. In that working
copy, you run 'svn info some/deep/file.c_at_50'. At that moment, you are
asserting your belief that /branches/my-branch/some/deep/file.c exists at
revision 50. You'd be wrong, of course. Instead, you should tell
Subversion only what you know, and allow it to help you figure out what you
may not. By saying 'svn info some/deep/file.c[@BASE] -r50' (the @BASE bit
is the default, but you can specify it explicitly if you wish), you tell
Subversion "I know that some/deep/file.c exists as it is represented in my
working copy, but I'm not sure where it lived back in r50 -- go find that
place for me and then perform the operation I requested."
Have I understood your concern? Is there something I can do to make that
book section more understandable?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-29 16:31:14 CEST