Re: Help explain peg revisions

Scott Palmer <scott.palmer@2connected.org> writes:
> On 16-Mar-06, at 2:09 PM, kfogel@collab.net wrote:
> > Scott Palmer <scott.palmer@2connected.org> writes:
> >> No. Actually Mr. Heppenstall is correct.
> >>
> >> I did the experiment. (Actually a slightly modified experiment using
> >> 'cat' instead of 'checkout')
> >>
> >> svn cat url-to-foo@5
> >>
> >> outputs the contents of 'foo' as it existed in revision 5, even
> >> though the head revision is different.
> >>
> >> Sadly there seems to be a bug because if foo is renamed to bar in the
> >> head revsion
> >>
> >> svn cat -rHEAD url-to-foo@5
> >>
> >> FAILS! the Error message is
> >> svn: File not found: revision 10, path '/path/to/foo'
> >>
> >> Where 10 is the revision of HEAD.
> >> This is NOT what I expected. I', using Subversion 1.3.0 on
> >> Windows XP.
> >> Peg revisions are broken it seems. At least for the 'svn cat'
> >> command.
> >
> > If the url-to-foo was renamed to url-to-bar sometime before r10 (i.e.,
> > before HEAD), then this is indeed an error.
>
> I'm not sure I understand. How is it possible to for ANYTHING to
> happen after HEAD since HEAD is by definition the latest?
> Do you mean that the rename could not be part of the changes in rev
> 10 (HEAD)? Why not?

Hmm, I don't quite understand your question (I wrote "before" not
"after"), but here's an example of what I meant:

   r1: add /foo
   r5: (/foo is still in the same location it's been in since r1)
   r7: rename /foo to /bar
   r8: change the contents of /bar
  r10: (no further changes to /foo or /bar, just noting that r10 is HEAD)

Now:

   $ svn cat -rHEAD url-to-foo@5

My claim is that this should cat the contents /bar has had since r8.
We used url-to-foo@5 to identify the object (i.e., identify the "line
of history"), and we used -rHEAD to identify what point along that
line of history we're interested in. That point is r10 (HEAD), and as
of r10, the object formerly known as /foo is now /bar, and has the
contents /bar has had since r8.

Clearer?

But I can think of one reason why Subversion might not be able to
behave this way today: renames are not yet perfectly implemented (see
issues #898 and #895) and appear as just "copy + delete". As was
pointed out elsewhere in this thread, since it's just a copy, the
source file could have been copied to multiple destinations -- in
which case, which of those destinations should be treated as the One
True Inheritor of the object's ancestry?

This problem is what the true renames work Garrett Rooney is doing
will fix, among other things.

> Here it is, but I think it is working correctly. The problem is
> perhaps in the documentation of peg revisions and what they are
> capable of.

I'll quote your full transcript in full, so everyone can see what
we're talking about:
 
> svnadmin create /tmp/repo
> mkdir wc
> echo Hello > wc/test.txt
> svn import wc file:///tmp/repo/peg_test -m "initial import"
> rm -r wc
> svn co file:///tmp/repo/peg_test
> echo Mom >> peg_test/test.txt
> svn st peg_test
> svn ci peg_test -m "changed contents"
> svn mv peg_test/test.txt peg_test/test_renamed.txt
> echo RENAMED >> peg_test/test_renamed.txt
> svn ci peg_test -m "renamed and changed contents"
> echo After Rename >> peg_test/test_renamed.txt
> svn ci peg_test -m "changed contents after rename"
> svn up peg_test
> svn log -v peg_test
> echo ---- test.txt@2 ----
> svn cat file:///tmp/repo/peg_test/test.txt_at_2
> echo ---- -rHEAD test.txt@2 ----
> svn cat -rHEAD file:///tmp/repo/peg_test/test.txt_at_2
>
>
> The output of which is:
>
> Adding wc/test.txt
>
> Committed revision 1.
> A peg_test/test.txt
> Checked out revision 1.
> M peg_test/test.txt
> Sending peg_test/test.txt
> Transmitting file data .
> Committed revision 2.
> A peg_test/test_renamed.txt
> D peg_test/test.txt
> Deleting peg_test/test.txt
> Adding peg_test/test_renamed.txt
> Transmitting file data .
> Committed revision 3.
> Sending peg_test/test_renamed.txt
> Transmitting file data .
> Committed revision 4.
> At revision 4.
> ------------------------------------------------------------------------
> r4 | scottpalmer | 2006-03-16 21:10:38 -0500 (Thu, 16 Mar 2006) | 1 line
> Changed paths:
> M /peg_test/test_renamed.txt
>
> changed contents after rename
> ------------------------------------------------------------------------
> r3 | scottpalmer | 2006-03-16 21:10:37 -0500 (Thu, 16 Mar 2006) | 1 line
> Changed paths:
> D /peg_test/test.txt
> A /peg_test/test_renamed.txt (from /peg_test/test.txt:2)
>
> renamed and changed contents
> ------------------------------------------------------------------------
> r2 | scottpalmer | 2006-03-16 21:10:35 -0500 (Thu, 16 Mar 2006) | 1 line
> Changed paths:
> M /peg_test/test.txt
>
> changed contents
> ------------------------------------------------------------------------
> r1 | scottpalmer | 2006-03-16 21:10:33 -0500 (Thu, 16 Mar 2006) | 1 line
> Changed paths:
> A /peg_test
> A /peg_test/test.txt
>
> initial import
> ------------------------------------------------------------------------
> ---- test.txt@2 ----
> Hello
> Mom
> ---- -rHEAD test.txt@2 ----
> svn: File not found: revision 4, path '/peg_test/test.txt'

Okay, yes, I think this reveals that peg revisions do not currently
work as (IMHO) they should. I'm going to link to this thread from
issue #898 or #895, just so there's some context for people following
the issue.

Scott, thanks for taking the time to go into depth, come up with a
transcript, etc. At least there are no unknown corners left here: we
have pretty much explored all the ways SVN *could* behave, and of
those ways, which ways it actually does behave right now.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org