You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sukhmeet Toor <to...@gmail.com> on 2005/06/27 16:24:23 UTC
Subversion produces inconsistent base revisions for move operations
Hi All,
I am working in a team to customize Trac
(http://www.edgewall.com/trac/), a lightweight project management
tool, for academic use. As part of developing a testing framework for
the project, I am trying to create a mock Subversion repository object
that would be able to replace the "real" subversion for the purposes
of testing. While working on this, I noticed some inconsistency in the
way subversion handles base revisions during move operations -- this
most probably means that I haven't fully understood the way subversion
works; hence this query.
Below is the output of a "svn log -v" issued at the top level of the
working copy of my test repository (my comments are indicated with *'s
below). Notice first that some moves are treated as a DELETE followed
by an ADD (r9), while some are treated as an ADD followed by a DELETE
(r4 and r8). The problem that I'm facing is that in r9, the base
revision for newdir is 8 while it should have been 4, as it was last
modified in revision 4 (moved from /dir). Now, my guess is that in
this case the DELETE happened before the ADD (and not in the reverse
order), and hence the base revision of /newdir got touched up to 8.
I need to get the base revisions for each node correct for my
implementation of a correct mock repository object. I'm unsure how
subversion works underneath, and how it decides the base revision for
nodes at each revision, and when a MOVE is treated as a DELETE
followed by an ADD and vice-versa. I am hoping someone can fill me in.
Thanks much,
Sukhmeet Toor
Argon Project
http://www.third-bit.com/trac/argon/
p.s. a dump of the test repository is attached.
"svn log -v" output follows:
==================
------------------------------------------------------------------------
r12 | stoor | 2005-06-27 11:19:31 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
D /dir2/newdir
------------------------------------------------------------------------
r11 | stoor | 2005-06-27 11:19:30 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
M /dir2/cool/b.txt
------------------------------------------------------------------------
r10 | stoor | 2005-06-27 11:19:28 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /dir2/cool (from /dir2/newdir:9)
------------------------------------------------------------------------
r9 | stoor | 2005-06-27 11:19:26 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /dir2/newdir (from /newdir:8)
D /newdir
* /newdir moved to /dir2/newdir -- D followed by A
* base revision for /newdir is 8 -- should have been 4
------------------------------------------------------------------------
r8 | stoor | 2005-06-27 11:19:24 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
D /dir2/f.txt
A /dir2/g.txt (from /dir2/f.txt:7)
* /dir2/f.txt moved to /dir2/g.txt -- A followed by D
------------------------------------------------------------------------
r7 | stoor | 2005-06-27 11:19:23 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
M /d.txt
A /dir2/f.txt
------------------------------------------------------------------------
r6 | stoor | 2005-06-27 11:19:22 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /dir2
------------------------------------------------------------------------
r5 | stoor | 2005-06-27 11:19:21 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /d.txt
A /e.txt
------------------------------------------------------------------------
r4 | stoor | 2005-06-27 11:19:20 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
D /a.txt
D /dir
A /newdir (from /dir:1)
A /newdir/b.txt (from /dir/b.txt:3)
A /newdir/c.txt (from /dir/c.txt:3)
* /dir moved to /newdir -- A followed by D
* base revision of /dir is 1
------------------------------------------------------------------------
r3 | stoor | 2005-06-27 11:19:18 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /dir/c.txt (from /a.txt:2)
------------------------------------------------------------------------
r2 | stoor | 2005-06-27 11:19:17 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
M /a.txt
A /dir/b.txt
------------------------------------------------------------------------
r1 | stoor | 2005-06-27 11:19:16 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /a.txt
A /dir
------------------------------------------------------------------------
Re: Subversion produces inconsistent base revisions for move operations
Posted by Sukhmeet Toor <to...@gmail.com>.
Hi Michael,
Thanks for your response. It turns out that my problem was indeed caused by
the WC getting "confused" as to which revision it is at which results when a
commit happens without an update. I take it that this is something inherent
in subversion, so I'll have to work with this.
Thanks a lot for your help.
Regards,
Sukhmeet
On 7/1/05, Michael Sinz <mi...@gmail.com> wrote:
>
> 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)
>
>
> --
> Michael Sinz Technology and Engineering Director/Consultant
> "Starting Startups" mailto:Michael.Sinz@sinz.org
> My place on the web http://www.sinz.org/Michael.Sinz
>
Re: Subversion produces inconsistent base revisions for move operations
Posted by kf...@collab.net.
Michael Sinz <mi...@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
Re: Subversion produces inconsistent base revisions for move operations
Posted by Michael Sinz <mi...@gmail.com>.
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)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion produces inconsistent base revisions for move
operations
Posted by Philip Martin <ph...@codematters.co.uk>.
Sukhmeet Toor <to...@gmail.com> writes:
> Thanks for your response. Look at r4 below; If base revision was taken
> as the working copy (WC) revision when the move operation was
> performed, then /newdir@4 should have been copied from /dir@3 (the WC
> was @3) and not from /dir@1 as the log indicates.
>
> ------------------------------------------------------------------------
> r4 | stoor | 2005-06-27 12:16:05 -0400 (Mon, 27 Jun 2005) | 1 line
> Changed paths:
> D /a.txt
> D /dir
> A /newdir (from /dir:1)
> A /newdir/b.txt (from /dir/b.txt:3)
> A /newdir/c.txt (from /dir/c.txt:3)
Obviously your assumption that the WC was at r3 is wrong.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion produces inconsistent base revisions for move operations
Posted by Sukhmeet Toor <to...@gmail.com>.
Hi Philip
Thanks for your response. Look at r4 below; If base revision was taken
as the working copy (WC) revision when the move operation was
performed, then /newdir@4 should have been copied from /dir@3 (the WC
was @3) and not from /dir@1 as the log indicates.
------------------------------------------------------------------------
r4 | stoor | 2005-06-27 12:16:05 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
D /a.txt
D /dir
A /newdir (from /dir:1)
A /newdir/b.txt (from /dir/b.txt:3)
A /newdir/c.txt (from /dir/c.txt:3)
------------------------------------------------------------------------
Any thoughts?
Thanks,
Sukhmeet
On 6/27/05, Philip Martin <ph...@codematters.co.uk> wrote:
> Sukhmeet Toor <to...@gmail.com> writes:
>
> > Notice first that some moves are treated as a DELETE followed
> > by an ADD (r9), while some are treated as an ADD followed by a DELETE
> > (r4 and r8).
>
> The order of the names in the log message does not imply that one
> happens before the other. As far as log is concerned they happen
> togther.
>
> > The problem that I'm facing is that in r9, the base
> > revision for newdir is 8 while it should have been 4, as it was last
> > modified in revision 4 (moved from /dir).
>
> Ever revision number applies to all items in the repository. newdir
> might be unchanged between r4 and r8, but that doesn't change the fact
> that you copied newdir from the r8 tree.
>
> --
> Philip Martin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion produces inconsistent base revisions for move
operations
Posted by Philip Martin <ph...@codematters.co.uk>.
Sukhmeet Toor <to...@gmail.com> writes:
> Notice first that some moves are treated as a DELETE followed
> by an ADD (r9), while some are treated as an ADD followed by a DELETE
> (r4 and r8).
The order of the names in the log message does not imply that one
happens before the other. As far as log is concerned they happen
togther.
> The problem that I'm facing is that in r9, the base
> revision for newdir is 8 while it should have been 4, as it was last
> modified in revision 4 (moved from /dir).
Ever revision number applies to all items in the repository. newdir
might be unchanged between r4 and r8, but that doesn't change the fact
that you copied newdir from the r8 tree.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Subversion produces inconsistent base revisions for move operations
Posted by Dale Worley <dw...@pingtel.com>.
> From: Sukhmeet Toor [mailto:toorsukhmeet@gmail.com]
>
> Thanks for a quick response; I understand that when something is
> moved/copied, it gets copied from a specific revision for a specific
> path. But, the issue is how subversion decides which revision to copy
> from. In the case specified, /dir2/newdir@9 was copied from /newdir@8
> (not @4 -- even if they're the same). Now compare this with r4 below.
> Here, /newdir@4 was copied from /dir@1 (and not from /dir@3) as we
> would have expected since the WC was at 3.
That's difficult to say, since you haven't shown us the sequence of commands
you executed to get into your situation. But my suspicion is that /dir was
at rev 1, even if other parts of your WC were at rev 3. What did "svn info
/dir" say at that moment?
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion produces inconsistent base revisions for move operations
Posted by Sukhmeet Toor <to...@gmail.com>.
Hi Dale
Thanks for a quick response; I understand that when something is
moved/copied, it gets copied from a specific revision for a specific
path. But, the issue is how subversion decides which revision to copy
from. In the case specified, /dir2/newdir@9 was copied from /newdir@8
(not @4 -- even if they're the same). Now compare this with r4 below.
Here, /newdir@4 was copied from /dir@1 (and not from /dir@3) as we
would have expected since the WC was at 3.
------------------------------------------------------------------------
r4 | stoor | 2005-06-27 12:16:05 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
D /a.txt
D /dir
A /newdir (from /dir:1)
A /newdir/b.txt (from /dir/b.txt:3)
A /newdir/c.txt (from /dir/c.txt:3)
------------------------------------------------------------------------
This is the problem that I'm facing. My objective here is only to read
a repository and generate the changesets for each revision
appropriately. So, my concern is not how to make /dir2/newdir@9 copy
from /newdir@4, but to understand which revisions are selected when
nodes are copied, so I can code some similar logic for my mock object.
Any other ideas?
Thanks again,
Sukhmeet
On 6/27/05, Dale Worley <dw...@pingtel.com> wrote:
> > From: Sukhmeet Toor [mailto:toorsukhmeet@gmail.com]
> >
> > Below is the output of a "svn log -v" issued at the top level of the
> > working copy of my test repository (my comments are indicated with *'s
> > below). Notice first that some moves are treated as a DELETE followed
> > by an ADD (r9), while some are treated as an ADD followed by a DELETE
> > (r4 and r8). The problem that I'm facing is that in r9, the base
> > revision for newdir is 8 while it should have been 4, as it was last
> > modified in revision 4 (moved from /dir). Now, my guess is that in
> > this case the DELETE happened before the ADD (and not in the reverse
> > order), and hence the base revision of /newdir got touched up to 8.
>
> Any time something is copied in the repository (and I assume, when something
> is moved), it is always copied from some specific revision of some specific
> path. in this case:
>
> ------------------------------------------------------------------------
> r9 | stoor | 2005-06-27 11:19:26 -0400 (Mon, 27 Jun 2005) | 1 line
> Changed paths:
> A /dir2/newdir (from /newdir:8)
> D /newdir
>
> /dir2/newdir@9 is copied from /newdir@8. Of course, /newdir@8 is the same
> as /newdir@4, but Subversion doesn't record that information at that moment.
> But this is what you expect if you have a WC at rev 8, do "svn mv /newdir
> /dir2/newdir", and commit -- /newdir in your WC was at rev 8.
>
> You could get the effect your are looking for my something grotty like "svn
> delete /newdir ; svn copy -r4 http://.../newdir /dir2/newdir", but why do
> you want to?
>
> Dale
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Subversion produces inconsistent base revisions for move operations
Posted by Dale Worley <dw...@pingtel.com>.
> From: Sukhmeet Toor [mailto:toorsukhmeet@gmail.com]
>
> Below is the output of a "svn log -v" issued at the top level of the
> working copy of my test repository (my comments are indicated with *'s
> below). Notice first that some moves are treated as a DELETE followed
> by an ADD (r9), while some are treated as an ADD followed by a DELETE
> (r4 and r8). The problem that I'm facing is that in r9, the base
> revision for newdir is 8 while it should have been 4, as it was last
> modified in revision 4 (moved from /dir). Now, my guess is that in
> this case the DELETE happened before the ADD (and not in the reverse
> order), and hence the base revision of /newdir got touched up to 8.
Any time something is copied in the repository (and I assume, when something
is moved), it is always copied from some specific revision of some specific
path. in this case:
------------------------------------------------------------------------
r9 | stoor | 2005-06-27 11:19:26 -0400 (Mon, 27 Jun 2005) | 1 line
Changed paths:
A /dir2/newdir (from /newdir:8)
D /newdir
/dir2/newdir@9 is copied from /newdir@8. Of course, /newdir@8 is the same
as /newdir@4, but Subversion doesn't record that information at that moment.
But this is what you expect if you have a WC at rev 8, do "svn mv /newdir
/dir2/newdir", and commit -- /newdir in your WC was at rev 8.
You could get the effect your are looking for my something grotty like "svn
delete /newdir ; svn copy -r4 http://.../newdir /dir2/newdir", but why do
you want to?
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org