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
I figured out with
which should end up with:
Resolved conflicted state of 'PATH_TO_FILE'
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.I am not able reproduce what you have mentioned. Here is what I have tried.
Apparently I tried the same approach which you did and did not face any problem again. What version of svn are you using ?
Try
Svn should then bring in a fresh
folder
directory version identical with the one fromco1
. You can then overwrite with the content fromfolder.SAVE
.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 :)