On Wed, 2009-09-30 at 13:11 +0100, Stefan Sperling wrote:
> On Tue, Sep 29, 2009 at 02:15:46PM -0400, Mark Phippard wrote:
> > I was sent the following problem description from one of our support
> > team. I am also attaching a script I wrote which shows it. This
> > seems like one of those cases where tree conflicts leaves your working
> > copy in a state where you cannot really do anything. In this case, I
> > am not sure what we should be doing. I kind of think this should not
> > be a tree conflict at all and dir1 should just become unversioned and
> > left on disk as we would have done prior to 1.6.
>
> So you're saying we should disable tree conflict checking during
> switch? I don't think that's a good idea.
>
> > 1) create branchA off trunk
> > 2) add dir1 with 4 files to branchA, commit
> > 3) modify a file(file1.txt) under dir1 on branch A, DONT commit
> > 4) do a switch from branch to trunk
>
> It's clear that there is a conflicting local modification. Essentially,
> the user was telling Subversion "I want this local mod for dir1/file1.txt
> on this branch, ... er, no no wait a second I want it on trunk even though
> dir1/file1.txt does not even yet exist on trunk".
>
> That is a tree conflict, so flagging a tree conflict is correct.
+1.
> > This will result in a tree conflict of dir1, as it does not exist on
> > trunk. I want this dir so I choose to keep it durring the resolve.
>
> So this dir should be in trunk as well as the in the branch.
> Sounds like this is not a job for 'switch', but a job for merge.
> Why not merge the dir, instead of switching and then adding?
-1. It's not fair to tell people that "switch" can't actually be used if
they have certain kinds of local mods anywhere in their tree, and they
should do something different instead.
Anyway, as you discovered, it works perfectly in trunk, with logical
semantics.
[...]
So, with 1.6.x, there is a bug somewhere in the region of:
- raising the tree conflict, when scheduling the dir to be added, it
doesn't schedule the dir's children properly
- "svn resolved" doesn't leave the WC in a state that can be
committed. ("Did not expect '/.../MyFile1.txt' to be a working copy
root").
But all you have to do to work around it is to complete the switch (by
repeating it) after marking the conflict as resolved:
[[[
$ ~/src/subversion-1.6.x/bin/svn st -v wc
3 1 julianfoad wc
3 1 julianfoad wc/MyProject
3 1 julianfoad wc/MyProject/MyFolder
3 1 julianfoad wc/MyProject/MyFolder/MyFile1.txt
3 1 julianfoad wc/MyProject/MyFolder/MyFile2.txt
A + - 3 julianfoad wc/MyProject/MyFolder2
M +S - 3 julianfoad wc/MyProject/MyFolder2/MyFile1.txt
+S - 3 julianfoad wc/MyProject/MyFolder2/MyFile2.txt
+S - 3 julianfoad wc/MyProject/MyFolder2/MyFile3.txt
+S - 3 julianfoad wc/MyProject/MyFolder2/MyFile4.txt
$ ~/src/subversion-1.6.x/bin/svn sw ^/trunk wc
At revision 3.
$ ~/src/subversion-1.6.x/bin/svn st -v wc
3 1 julianfoad wc
3 1 julianfoad wc/MyProject
3 1 julianfoad wc/MyProject/MyFolder
3 1 julianfoad wc/MyProject/MyFolder/MyFile1.txt
3 1 julianfoad wc/MyProject/MyFolder/MyFile2.txt
A + - 3 julianfoad wc/MyProject/MyFolder2
M + - 3 julianfoad wc/MyProject/MyFolder2/MyFile1.txt
+ - 3 julianfoad wc/MyProject/MyFolder2/MyFile2.txt
+ - 3 julianfoad wc/MyProject/MyFolder2/MyFile3.txt
+ - 3 julianfoad wc/MyProject/MyFolder2/MyFile4.txt
]]]
And after that the commit works as expected (adding the whole directory
tree as a copy of the branch, and making the modification to
MyFile1.txt).
[[[
$ ~/src/subversion-1.6.x/bin/svn ci -m "" wc
Adding wc/MyProject/MyFolder2
Sending wc/MyProject/MyFolder2/MyFile1.txt
Transmitting file data .
Committed revision 4.
$ (cd wc && ~/src/subversion-1.6.x/bin/svn diff ^/trunk ^/branches/r01)
Index: MyProject/MyFolder2/MyFile1.txt
===================================================================
--- MyProject/MyFolder2/MyFile1.txt (.../trunk) (revision 4)
+++ MyProject/MyFolder2/MyFile1.txt (.../branches/r01) (revision 4)
@@ -1 +1 @@
-//Edit My Cool File
+//My Cool File
]]]
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2402064
Received on 2009-09-30 14:54:34 CEST