[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflict bug with switch

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 29 Sep 2009 15:18:43 -0400

Euh... I thought we were supposed to disallow a switch if localmods existed.
Did that requirement get relaxed? Why? It doesn't seem reasonable at all to
allow localmods on one path to magically be applicable to another.


On Sep 29, 2009 2:16 PM, "Mark Phippard" <markphip_at_gmail.com> 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.

----- begin paste -------
Steps to reproduce
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

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.

Now I have a directory that is scheduled to be added to trunk, with
files that are still switched to the branch. I cannot commit the
change I made to file1.txt as it will error out.

I can however just commit the 'add' of the new directory, but the
files are still pointing to the branch, in fact I can then commit my
change but it actually commits to the branch, not the trunk.

If I then delete the directory after adding it and update it pulls in
the new directory and all the contents, all pointing to trunk (even
though the files were never added).
----- end paste -------

Mark Phippard
Received on 2009-09-29 21:19:06 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.