Michael Sinz <michael.sinz@gmail.com> writes:
> It is very easy to get confused as to what revision the WC thinks it
> is at and what it "feels" like it is at. That is not to say that the WC
> is incorrect, just that it "feels" wrong due to the behavior of the
> system.
>
> Here is one of the strange results I get that are, to me at least, very
> un-nerving and yet somewhat correct:
>
> For example, I just did this set of commands:
>
> mks@localhost:example/fold> svn up
> At revision 12.
>
> mks@localhost:example/fold> svn status
> M fold.js
>
> mks@localhost:example/fold> svn info .
> Path: .
> URL: https://svn.code-host.net/svn/example/trunk/fold
> Repository UUID: 7e4e2bb8-96f4-0310-a956-93822b521e05
> Revision: 12
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mks
> Last Changed Rev: 7
> Last Changed Date: 2005-04-18 21:13:56 -0400 (Mon, 18 Apr 2005)
>
>
> mks@localhost:example/fold> svn commit -m 'Test commit'
> Sending fold/fold.js
> Transmitting file data .
> Committed revision 13.
>
> mks@localhost:example/fold> svn status
>
> mks@localhost:example/fold> svn info .
> Path: .
> URL: https://svn.code-host.net/svn/example/trunk/fold
> Repository UUID: 7e4e2bb8-96f4-0310-a956-93822b521e05
> Revision: 12
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mks
> Last Changed Rev: 7
> Last Changed Date: 2005-04-18 21:13:56 -0400 (Mon, 18 Apr 2005)
>
>
> Note that the svn info still said revision 12 (and cwd 7) even though
> I just committed a file there.
>
> Now, if I do a svn cp at this point and then log:
> mks@localhost:example/fold> svn cp .
> https://svn.code-host.net/svn/example/branches/test1-branch
>
> Committed revision 14.
>
> mks@localhost:example/fold> svn log -v --stop-on-copy
> https://svn.code-host.net/svn/example/branches/test1-branch
> ------------------------------------------------------------------------
> r14 | mks | 2005-07-01 22:23:39 -0400 (Fri, 01 Jul 2005) | 2 lines
> Changed paths:
> A /branches/test1-branch (from /trunk/fold:12)
> R /branches/test1-branch/fold.js (from /trunk/fold/fold.js:13)
>
> Test of a cp . without first a up...
>
> ------------------------------------------------------------------------
>
> Note how the revision used was 12 but then a R was done on the one
> file that was different (even though it was checked in at 13)
>
> mks@localhost:example/fold> svn up
> At revision 14.
> [1] + Done nedit fold.js
>
> mks@localhost:example/fold> svn info .
> Path: .
> URL: https://svn.code-host.net/svn/example/trunk/fold
> Repository UUID: 7e4e2bb8-96f4-0310-a956-93822b521e05
> Revision: 14
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mks
> Last Changed Rev: 13
> Last Changed Date: 2005-07-01 22:16:22 -0400 (Fri, 01 Jul 2005)
>
> mks@localhost:example/fold> svn cp .
> https://svn.code-host.net/svn/example/branches/test2-branch
>
> Committed revision 15.
>
> mks@localhost:example/fold> svn log -v --stop-on-copy
> https://svn.code-host.net/svn/example/branches/test2-branch
> ------------------------------------------------------------------------
> r15 | mks | 2005-07-01 22:29:51 -0400 (Fri, 01 Jul 2005) | 2 lines
> Changed paths:
> A /branches/test2-branch (from /trunk/fold:14)
>
> Test of a cp . after an up...
>
> ------------------------------------------------------------------------
>
> Now, I did this with a directory, but the same happens with
> individual files. So the WC's idea of where you are at is
> very much a factor in how the actual commits are done
> and what they look like.
>
> (BTW - I think it is a bug to have done a commit and yet not
> have the WC correctly reflect that but it is a non-trivial problem
> to address - very non-trivial given the fact that other parts of
> the tree may not be updated or committed to match the new
> revision... So the current behavior, while a bit confusing does
> produce valid results which is the main issue)
The WC is correctly reflecting everything, given the questions you're
asking it. For example, if you did 'svn status -v', you'd see the
file you'd committed as at r13, with the rest of the working copy at
still at r12.
Your speculations about why this is so is exactly right: other parts
of the WC have not been updated, so they cannot claim to know anything
about other changes.
Do you know about the 'svnversion' program, whose purpose is to
summarize the state of such mixed-revision working copies?
It just now occurred to me that if the WC is at rN, and you commit
r(N+1) from that working copy, then the entire working copy could be
marked as r(N+1), because no non-integral revision could possibly
exist between N and N+1. However, this is a special case, and the
busier the repository, the more rare it would be, so I'm not sure it's
worth any extra code to support it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 2 07:03:17 2005