C. Michael Pilato wrote:
> 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."
I expect Vincent is asking how 'svn' interprets 'svn info
some/deep/file.c_at_50'. It does accept such target specifiers (at least
for some commands) but it's not clear how it does or should interpret
them.
Some possible interpretations are
* Find the repository URL of './some/deep/file.c', and look up that
URL in r50. If the line of history of the local file had been moved
since then, the look-up will probably fail or perhaps find an unrelated
node. If the line of history had not been moved since that revision,
then the peg specifier '@50' would have the same effect as an operative
revision '-r50', or would be redundant if an operative revision was
already specified.
* Find the repository URL of './some/deep/file.c', and follow its
history (through copies) back to r50. With this interpretation, the peg
specifier '@50' would have the same effect as an operative revision
'-r50', or would be redundant if an operative revision was already
specified.
* Error: the peg of a local item is necessarily that local working
version of that node. Your working copy is the version of the project
tree in which we first look up the path you specify, and from where we
can trace to other versions in the repository if required. The tree
formed by your working copy does not exist (or rather may not have
existed and was not recorded) on historical revisions, so it doesn't
make any sense to specify any other revision in which to first interpret
a local path.
Have I got that about right?
- Julian
> Have I understood your concern? Is there something I can do to make that
> book section more understandable?
>
Received on 2010-03-29 18:08:08 CEST