SVN how to resolve "local add, incoming add upon update" on a *folder*?

Question

Here is my scenario:

Assume we have an SVN repo with the following content: myfolder myfolder\file.txt

Now I create two checkouts of this repo, co1 and co2.

In co1 we modify file.txt. In co2 we:

• svn delete myfolder
• svn commit
• Create a new folder named myfolder
• svn add myfolder
• svn commit

Now if I attempt an update in co1 I get a tree conflict:

A  +  C myfolder >   local edit, incoming delete upon update
M  +    myfolder\file.txt

I want to keep myfolder and the modified file, so I resolve the tree conflict:

svn resolve --accept working folder

Now if I try to commit, I get "svn: Directory '/myfolder' is out of date". If I try to resolve this using svn up myfolder, I get a tree conflict again:

A  +  C folder >   local add, incoming add upon update
M  +    myfolder\file.txt

Okay, so we try svn resolve --accept working folder again. But we still can't commit, we get the same message that "svn: Directory '/myfolder' is out of date", if we do svn up myfolder, we get right back to the last tree conflict.

What is the correct procedure to resolve this type of conflict (when we wish to keep myfolder and its changes)?

EDIT: Windows cmd line script to illustrate:

rmdir /S /Q C:\svntest 
mkdir C:\svntest

cd C:\svntest

svnadmin create repo

svn co file:///c:/svntest/repo co1
svn co file:///c:/svntest/repo co2

cd co1
mkdir folder
echo content > folder\file.txt
svn add folder
svn commit folder -m ""

cd C:\svntest\co2
svn up

cd C:\svntest\co1
svn del folder
svn commit -m ""
mkdir folder
svn add folder
svn commit -m ""

cd C:\svntest\co2
echo changed_content > folder\file.txt
svn up
svn resolve --accept working folder
svn commit -m ""

svn up folder
svn resolve --accept working folder
svn commit -m ""

And here is the output of running that script (note the commit failures at the end):

C:\>rmdir /S /Q C:\svntest  

C:\>mkdir C:\svntest 

C:\>cd C:\svntest 

C:\svntest>svnadmin create repo 

C:\svntest>svn co file:///c:/svntest/repo co1 
Checked out revision 0.

C:\svntest>svn co file:///c:/svntest/repo co2 
Checked out revision 0.

C:\svntest>cd co1 

C:\svntest\co1>mkdir folder 

C:\svntest\co1>echo content  1>folder\file.txt 

C:\svntest\co1>svn add folder 
A         folder
A         folder\file.txt

C:\svntest\co1>svn commit folder -m "" 
Adding         folder
Adding         folder\file.txt
Transmitting file data .
Committed revision 1.

C:\svntest\co1>cd C:\svntest\co2 

C:\svntest\co2>svn up 
A    folder
A    folder\file.txt
Updated to revision 1.

C:\svntest\co2>cd C:\svntest\co1 

C:\svntest\co1>svn del folder 
D         folder\file.txt
D         folder

C:\svntest\co1>svn commit -m "" 
Deleting       folder

Committed revision 2.

C:\svntest\co1>mkdir folder 

C:\svntest\co1>svn add folder 
A         folder

C:\svntest\co1>svn commit -m "" 
Adding         folder

Committed revision 3.

C:\svntest\co1>cd C:\svntest\co2 

C:\svntest\co2>echo changed_content  1>folder\file.txt 

C:\svntest\co2>svn up 
C folder
At revision 3.
Summary of conflicts:
  Tree conflicts: 1

C:\svntest\co2>svn resolve --accept working folder 
Resolved conflicted state of 'folder'

C:\svntest\co2>svn commit -m "" 
Adding         folder
svn: Commit failed (details follow):
svn: Directory '/folder' is out of date

C:\svntest\co2>svn up folder 
   C folder
At revision 3.
Summary of conflicts:
  Tree conflicts: 1

C:\svntest\co2>svn resolve --accept working folder 
Resolved conflicted state of 'folder'

C:\svntest\co2>svn commit -m "" 
Adding         folder
svn: Commit failed (details follow):
svn: Directory '/folder' is out of date

Evacuation

@Azirath: I updated my answer, can you tell me what version of svn you are using ? – Canakin

Sorry for the long response time, i had to get this unregistered account merged with my real account. See my answer in the comments to your answer. – Evacuation

Answer 1

I figured out with

svn resolve --accept working  PATH_TO_FILE

which should end up with:

Resolved conflicted state of 'PATH_TO_FILE'

Svoboda

See the documentation for options aside from 'working'. – Balsaminaceous

Answer 2

Tree Conflicts gives a nice overview of tree conflicts and their resolution. In some cases svn revert might help as well, while loosing all your local modifications. As last resort a new working copy with manually merged changes from the 'broken' one will bring you back on track. Definitely the dark side of subversion.

Soult

Unfortunately i already checked that overview of tree conflicts, but sadly it doesnt tell me how to resolve this specific scenario. I encountered this problem in our application that relies on SVN to handle certain user, not on the commandline, and therefore I would really like to avoid strange hacks and stick to using the SVN API. – Evacuation

I just had a problem with a tree conflict error of "Tree conflict: local add, incoming add upon update". I tried the svn revert option you suggested and that worked great. I completely forgot I could do that (since I hardly ever have to use that command). Thanks! – Spindly

Answer 3

Try

C:\svntest\co2>move folder folder.SAVE
C:\svntest\co2>svn revert folder
C:\svntest\co2>svn update

Svn should then bring in a fresh folder directory version identical with the one from co1. You can then overwrite with the content from folder.SAVE.

Ewell

Answer 4

I am not able reproduce what you have mentioned. Here is what I have tried.

test@test:/tmp$ cd /tmp/ 
test@test:/tmp$ svn co http://localhost:8080/svn/stackoverflow so --username=admin
A    so/trunk
A    so/branches
A    so/tags
Checked out revision 1.
test@test:/tmp$ cd so/trunk/ 
test@test:/tmp/so/trunk$ mkdir x 
test@test:/tmp/so/trunk$ ls /tmp > x/test.txt 
test@test:/tmp/so/trunk$ svn add x/ 
A         x
A         x/test.txt
test@test:/tmp/so/trunk$ svn ci -m "test"
Adding         trunk/x
Adding         trunk/x/test.txt
Transmitting file data .
Committed revision 2.
test@test:/tmp/so/trunk$ cd /tmp/ 
test@test:/tmp$ svn co http://localhost:8080/svn/stackoverflow so1 --username=admin 
A    so1/trunk
A    so1/trunk/x
A    so1/trunk/x/test.txt
A    so1/branches
A    so1/tags
Checked out revision 2.
test@test:/tmp$ cd /tmp/so1/trunk/ 
test@test:/tmp/so1/trunk$ svn remove x 
D         x/test.txt
D         x
test@test:/tmp/so1/trunk$ svn ci -m "" 
Deleting       trunk/x

Committed revision 3.
test@test:/tmp/so1/trunk$ mkdir x 
test@test:/tmp/so1/trunk$ cp ../../so/trunk/x/test.txt x 
test@test:/tmp/so1/trunk$ ll /tmp > x/test.txt 
test@test:/tmp/so1/trunk$ svn add x/ 
A         x
A         x/test.txt
test@test:/tmp/so1/trunk$ svn ci -m ""
Adding         trunk/x
Adding         trunk/x/test.txt
Transmitting file data .
Committed revision 4.
test@test:/tmp$ cd so/trunk/
test@test:/tmp/so/trunk$ svn up
D    x
A    x
A    x/test.txt
Updated to revision 4.
test@test:/tmp/so/trunk$ 

Apparently I tried the same approach which you did and did not face any problem again. What version of svn are you using ?

export REPOPATH=/tmp/svntest
test@test:/tmp/co2/trunk$ rm -rf $REPOPATH
test@test:/tmp/co2/trunk$ mkdir $REPOPATH
test@test:/tmp/co2/trunk$ svnadmin create $REPOPATH/repo
test@test:/tmp/co2/trunk$ svn co file:///$REPOPATH/repo co1
svn: Repository UUID '2d803eb8-2030-4dd3-bb6f-34ab07c74813' doesn't match expected UUID '82764ae8-6410-4565-933f-9a420cb60013'
test@test:/tmp/co2/trunk$ svn co file:///$REPOPATH/repo co2
svn: Repository UUID '2d803eb8-2030-4dd3-bb6f-34ab07c74813' doesn't match expected UUID '82764ae8-6410-4565-933f-9a420cb60013'
test@test:/tmp/co2/trunk$ 
test@test:/tmp/co2/trunk$ cd $REPOPATH/co1
bash: cd: /tmp/svntest/co1: No such file or directory
test@test:/tmp/co2/trunk$ mkdir folder
mkdir: cannot create directory `folder': File exists
test@test:/tmp/co2/trunk$ echo content > folder/file.txt
test@test:/tmp/co2/trunk$ svn add folder
svn: warning: 'folder' is already under version control
test@test:/tmp/co2/trunk$ svn commit folder -m ""
test@test:/tmp/co2/trunk$ 
test@test:/tmp/co2/trunk$ cd $REPOPATH/co2
bash: cd: /tmp/svntest/co2: No such file or directory
test@test:/tmp/co2/trunk$ svn up
At revision 10.
test@test:/tmp/co2/trunk$ 
test@test:/tmp/co2/trunk$ cd $REPOPATH/co1
bash: cd: /tmp/svntest/co1: No such file or directory
test@test:/tmp/co2/trunk$ svn del folder
svn: Use --force to override this restriction
svn: 'folder/file.txt' is not under version control
test@test:/tmp/co2/trunk$ svn commit -m ""
test@test:/tmp/co2/trunk$ mkdir folder
mkdir: cannot create directory `folder': File exists
test@test:/tmp/co2/trunk$ svn add folder
svn: warning: 'folder' is already under version control
test@test:/tmp/co2/trunk$ svn commit -m ""
test@test:/tmp/co2/trunk$ 
test@test:/tmp/co2/trunk$ cd $REPOPATH/co2
bash: cd: /tmp/svntest/co2: No such file or directory
test@test:/tmp/co2/trunk$ echo changed_content > folder\file.txt
test@test:/tmp/co2/trunk$ svn up
At revision 10.
test@test:/tmp/co2/trunk$ svn --version
svn, version 1.6.6 (r40053)
   compiled Dec 12 2009, 05:04:54

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

Canakin

I have added a script to the original post to illustrate my scenario in more detail. – Evacuation

The difference seems to be that in my scenario the file is modified in the working copy that performs the update ("so"), not the working copy that performs the delete ("so1") as is the case in your script. – Evacuation

Im not sure whats going on in your output, you seem to be getting alot of errors? – Evacuation

Anyway, i added the output of running my script to the original post, so you can see the output i am getting. I have tried it using SVN 1.6.6 and 1.6.12. – Evacuation

Answer 5

In this particular case, I think you'll have to re-apply the local changes manually. That is, create a patch file (svn diff > mine.patch, or copy files somewhere else), revert your changes or resolve using theirs, then apply the patch (or copy files back). Perhaps you will need to svn copy the base of your files back in the recreated folder before applying your changes.

Like zellus said, it's the dark side of subversion, and this is something the current implementation is unable to handle. Then again, deleting a folder and adding an identically named one back in doesn't sound quite right. What would you expect subversion to do? What if the file is not recreated in the folder? What if its content is different?

Try avoiding the situation altogether by not deleting a folder you want to keep :)

Romola

As mentioned previously we encounter this problem in our applications use of SVN (through SharpSVN) as an internal versioning system for shared user data. In our scenario it is not the same user that deletes the folder, rather its a server side delete that causes the next client that updates to recreate the folder. I simply expected SVN to give me a way of specifying that the current content of my working copy has been merged with the given revision on the server, thus allowing me to commit the result. – Evacuation