You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.net> on 2010/03/26 10:29:36 UTC
description of Peg Revision Algorithm is incomplete
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.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
> Vincent Lefevre wrote:
> [...]
>> Actually, I don't think that peg revisions (i.e. without following the
>> history) make much sense on objects relative to the current directory
>> (unless its URL has not changed since the peg-rev).
>
> That is the point I was trying to make: a peg rev specifier as defined
> in this thread does not make any sense on a local path, and so should
> not be allowed.
I deleted a similar statement from a previous mail after convincing myself
that surely we allowed that syntax for *some* reason before. Alas, I still
can't think of a compelling reason to allow it myself. :-P
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: description of Peg Revision Algorithm is incomplete
Posted by Julian Foad <ju...@wandisco.com>.
Vincent Lefevre wrote:
[...]
> Actually, I don't think that peg revisions (i.e. without following the
> history) make much sense on objects relative to the current directory
> (unless its URL has not changed since the peg-rev).
That is the point I was trying to make: a peg rev specifier as defined
in this thread does not make any sense on a local path, and so should
not be allowed.
- Julian
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 21:36:27 +0200, Stefan Sperling wrote:
> Maybe we could some day extend peg revision syntax so that every
> component of a path can be pegged?
>
> So what Vincent wants would be something like this:
>
> $ svn cat .@50/some/file.c
I almost proposed this, but the syntax would not be this one. Indeed,
if I understand correctly, .@50 means the URL of the current directory
at revision 50, while I want the current directory at revision 50,
taking into account the possible renamings (i.e. not a peg-rev on ".",
but -r50 on "."). Now, one could imagine a slightly different syntax,
e.g.
svn cat .@:50/some/file.c
where ":" means that one follows the history (like with -r).
Actually, I don't think that peg revisions (i.e. without following the
history) make much sense on objects relative to the current directory
(unless its URL has not changed since the peg-rev).
> And make svn treat a double-@ as actual @:
>
> $ ls
> dir@example.com
> $ svn cat dir@@example.com/file.c
Yes.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 21:36:27 +0200, Stefan Sperling wrote:
> Maybe we could some day extend peg revision syntax so that every
> component of a path can be pegged?
>
> So what Vincent wants would be something like this:
>
> $ svn cat .@50/some/file.c
I almost proposed this, but the syntax would not be this one. Indeed,
if I understand correctly, .@50 means the URL of the current directory
at revision 50, while I want the current directory at revision 50,
taking into account the possible renamings (i.e. not a peg-rev on ".",
but -r50 on "."). Now, one could imagine a slightly different syntax,
e.g.
svn cat .@:50/some/file.c
where ":" means that one follows the history (like with -r).
Actually, I don't think that peg revisions (i.e. without following the
history) make much sense on objects relative to the current directory
(unless its URL has not changed since the peg-rev).
> And make svn treat a double-@ as actual @:
>
> $ ls
> dir@example.com
> $ svn cat dir@@example.com/file.c
Yes.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 30, 2010 at 03:21:45PM -0400, C. Michael Pilato wrote:
> Vincent Lefevre wrote:
> > On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote:
> >> Interactions in the working copy with the path some/file.c only make sense
> >> if there is actually such a path in the working copy. If some/file.c is
> >> deleted in r51, then either it isn't in your working copy (because you've
> >> updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
> >> some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
> >> meaning anyway, so it falls to you to spelunk history and tell Subversion
> >> more precisely what object you're talking about.
> >
> > I want a simple way to say: consider the current directory at r50
> > (walking back through the history) and the object some/file.c in
> > it at the same revision.
>
> I'm sure you're not alone, but Subversion doesn't cleanly provide such a way
> today.
>
> $ svn cat `svn info some/ -r50 | grep ^URL: | cut -c 6-`/file.c@50
Maybe we could some day extend peg revision syntax so that every
component of a path can be pegged?
So what Vincent wants would be something like this:
$ svn cat .@50/some/file.c
And make svn treat a double-@ as actual @:
$ ls
dir@example.com
$ svn cat dir@@example.com/file.c
On the surface, this would be a natural extension to the current peg
rev syntax, which only looks for @ at the very end of the entire path.
Whoever actually does this should be well prepared for some serious
wrestling with the current APIs though... this would not be a simple
change. I guess it would easily size up to at least a google summer
of code project.
Stefan
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
Vincent Lefevre wrote:
> On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote:
>> Interactions in the working copy with the path some/file.c only make sense
>> if there is actually such a path in the working copy. If some/file.c is
>> deleted in r51, then either it isn't in your working copy (because you've
>> updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
>> some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
>> meaning anyway, so it falls to you to spelunk history and tell Subversion
>> more precisely what object you're talking about.
>
> I want a simple way to say: consider the current directory at r50
> (walking back through the history) and the object some/file.c in
> it at the same revision.
I'm sure you're not alone, but Subversion doesn't cleanly provide such a way
today.
$ svn cat `svn info some/ -r50 | grep ^URL: | cut -c 6-`/file.c@50
:-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote:
> Interactions in the working copy with the path some/file.c only make sense
> if there is actually such a path in the working copy. If some/file.c is
> deleted in r51, then either it isn't in your working copy (because you've
> updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
> some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
> meaning anyway, so it falls to you to spelunk history and tell Subversion
> more precisely what object you're talking about.
I want a simple way to say: consider the current directory at r50
(walking back through the history) and the object some/file.c in
it at the same revision.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote:
> Interactions in the working copy with the path some/file.c only make sense
> if there is actually such a path in the working copy. If some/file.c is
> deleted in r51, then either it isn't in your working copy (because you've
> updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
> some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
> meaning anyway, so it falls to you to spelunk history and tell Subversion
> more precisely what object you're talking about.
I want a simple way to say: consider the current directory at r50
(walking back through the history) and the object some/file.c in
it at the same revision.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
Vincent Lefevre wrote:
> On 2010-03-30 09:31:27 -0400, C. Michael Pilato wrote:
>> Nobody should be trying to run 'svn cat some/file.c@50' if what they mean is
>> "follow the history of some/file.c back to r50 and cat the contents there".
>> That's just not the correct syntax for invoking the algorithm, and no
>> amount of wishful thinking will change that. The correct syntax for that
>> request is 'svn cat some/file.c -r50'.
>
> This syntax doesn't work if some/file.c is deleted in r51.
> So, what would be the syntax to get some/file.c from r50 in
> this case?
Interactions in the working copy with the path some/file.c only make sense
if there is actually such a path in the working copy. If some/file.c is
deleted in r51, then either it isn't in your working copy (because you've
updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
meaning anyway, so it falls to you to spelunk history and tell Subversion
more precisely what object you're talking about.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 09:31:27 -0400, C. Michael Pilato wrote:
> Nobody should be trying to run 'svn cat some/file.c@50' if what they mean is
> "follow the history of some/file.c back to r50 and cat the contents there".
> That's just not the correct syntax for invoking the algorithm, and no
> amount of wishful thinking will change that. The correct syntax for that
> request is 'svn cat some/file.c -r50'.
This syntax doesn't work if some/file.c is deleted in r51.
So, what would be the syntax to get some/file.c from r50 in
this case?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-30 09:31:27 -0400, C. Michael Pilato wrote:
> Nobody should be trying to run 'svn cat some/file.c@50' if what they mean is
> "follow the history of some/file.c back to r50 and cat the contents there".
> That's just not the correct syntax for invoking the algorithm, and no
> amount of wishful thinking will change that. The correct syntax for that
> request is 'svn cat some/file.c -r50'.
This syntax doesn't work if some/file.c is deleted in r51.
So, what would be the syntax to get some/file.c from r50 in
this case?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
Vincent Lefevre wrote:
> Couldn't peg-rev be also taken into account to translate a working copy
> object into a URL? This would make sense if the parent directory has
> been renamed: as peg-rev is used to point to some object in the past,
> one should consider what the URL was in the past.
No, because peg revisions aren't about translation. They are about
selection. They are the waypoints or landmarks or some-other-
navigationally-analogous-thing by which Subversion determines which line of
history you are talking about. After -- and only after -- that selection is
made, translation occurs via the operational revision(s).
Nobody should be trying to run 'svn cat some/file.c@50' if what they mean is
"follow the history of some/file.c back to r50 and cat the contents there".
That's just not the correct syntax for invoking the algorithm, and no
amount of wishful thinking will change that. The correct syntax for that
request is 'svn cat some/file.c -r50'.
I'll grant that Subversion does have a sort of pre-translation step there
where it converts working copy paths to URLs, but that step already has
clear rules that perhaps just need some spelling out in the docs.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-29 12:36:11 -0400, C. Michael Pilato wrote:
> I was about to post that one place where there might be a lack of
> documentation is not so much in understanding what the peg revision means,
> but in understanding the "working copy path" -> "peg path" translation. The
> peg path algorithm works in repository path/rev space only. So any time a
> working copy path needs to be fed into that algorithm, it must be translated
> into a repository path (which on the client side comes in the form of a
> repository URL). To make that transformation, Subversion will resolve any
> working copy target path into its URL *as recorded in the working copy*,
> then use that as the path portion of the (path, peg-rev) input to the peg
> revision algorithm.
>
> And yes, as Greg points out, when a working copy object has no URL (because
> it is new and scheduled for addition), then the URL is probably constructed
> by tacking the object's basename onto the parent's URL.
Couldn't peg-rev be also taken into account to translate a working copy
object into a URL? This would make sense if the parent directory has
been renamed: as peg-rev is used to point to some object in the past,
one should consider what the URL was in the past.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-03-29 12:36:11 -0400, C. Michael Pilato wrote:
> I was about to post that one place where there might be a lack of
> documentation is not so much in understanding what the peg revision means,
> but in understanding the "working copy path" -> "peg path" translation. The
> peg path algorithm works in repository path/rev space only. So any time a
> working copy path needs to be fed into that algorithm, it must be translated
> into a repository path (which on the client side comes in the form of a
> repository URL). To make that transformation, Subversion will resolve any
> working copy target path into its URL *as recorded in the working copy*,
> then use that as the path portion of the (path, peg-rev) input to the peg
> revision algorithm.
>
> And yes, as Greg points out, when a working copy object has no URL (because
> it is new and scheduled for addition), then the URL is probably constructed
> by tacking the object's basename onto the parent's URL.
Couldn't peg-rev be also taken into account to translate a working copy
object into a URL? This would make sense if the parent directory has
been renamed: as peg-rev is used to point to some object in the past,
one should consider what the URL was in the past.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson wrote:
> On Mon, 2010-03-29 at 12:07 -0400, Julian Foad wrote:
>> Some possible interpretations are
>>
>> * Find the repository URL of './some/deep/file.c', and [...]
>
> I'll mention a related interpretation, which is to use the repository
> URL of the parent directory and append file.c to it.
>
> This is a little weird, and probably only makes sense as a fallback if
> the file doesn't have a URL (e.g. because it doesn't exist in the
> working copy), but it would let you do things like "svn cp
> deleted-file@1000 ."
>
> I may have filed an issue about this somewhere, possibly in the days
> before peg-revs.
I was about to post that one place where there might be a lack of
documentation is not so much in understanding what the peg revision means,
but in understanding the "working copy path" -> "peg path" translation. The
peg path algorithm works in repository path/rev space only. So any time a
working copy path needs to be fed into that algorithm, it must be translated
into a repository path (which on the client side comes in the form of a
repository URL). To make that transformation, Subversion will resolve any
working copy target path into its URL *as recorded in the working copy*,
then use that as the path portion of the (path, peg-rev) input to the peg
revision algorithm.
And yes, as Greg points out, when a working copy object has no URL (because
it is new and scheduled for addition), then the URL is probably constructed
by tacking the object's basename onto the parent's URL.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: description of Peg Revision Algorithm is incomplete
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2010-03-29 at 12:07 -0400, Julian Foad wrote:
> Some possible interpretations are
>
> * Find the repository URL of './some/deep/file.c', and [...]
I'll mention a related interpretation, which is to use the repository
URL of the parent directory and append file.c to it.
This is a little weird, and probably only makes sense as a fallback if
the file doesn't have a URL (e.g. because it doesn't exist in the
working copy), but it would let you do things like "svn cp
deleted-file@1000 ."
I may have filed an issue about this somewhere, possibly in the days
before peg-revs.
Re: description of Peg Revision Algorithm is incomplete
Posted by Julian Foad <ju...@wandisco.com>.
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@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@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?
>
Re: description of Peg Revision Algorithm is incomplete
Posted by "C. Michael Pilato" <cm...@collab.net>.
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@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand