NOTE: Subversion's new tree conflicts feature is something you need to learn about. Otherwise it will bite you later and you will be left with an uncommitted change and confusion about how to get it committed. Take a few moments to read this article.
SVN 1.6 Client + 1.5 Server = "Error: Aborting commit: 'C:\SVN\source-branch\src\item.vssscc' remains in conflict " and the file is gone. It's just gone!
Subversion 1.6 has been out for awhile and quite a few of us just upgraded our TortoiseSVN clients because there was a new version. There are some new features with it that make it desirable (including externals support for files, file system storage improvements, etc).
Perhaps the most important new feature we learn about (usually the hard way during a merge) is a new feature call Tree Conflicts. Just what are tree conflicts? Submerged, the CollabNet Subversion Blog talks about these conflicts:
Subversion 1.6.0 expands this concept to cover conflicts at the directory level, e.g. you locally delete a file then an update tries to bring a text change down on that file. These new types of conflicts are called tree conflicts.
I think the best definition is in the subversion book:
What happens if your collaborators move or delete a file that you are still working on? Maybe there was a miscommunication, and one person thinks the file should be deleted, while another person still wants to commit changes to the file. Or maybe your collaborators did some refactoring, renaming files and moving around directories in the process. If you were still working on these files, those modifications may need to be applied to the files at their new location. Such conflicts manifest themselves at the directory tree structure level rather than at the file content level, and are known as tree conflicts.
To further explain a tree conflict is when SVN notices changes in a directory. Like a file gets renamed to something else. Then someone tries to edit the original file in a branch or in the mainline (or in the same line before getting latest). What they are going to get on the next subversion update or merge is a tree conflict.
If you still don't understand what a tree conflict is and how it affects you, I encourage you to read the links above that explain it in detail.
SVN 1.5 & SVN 1.6 Do NOT Play Well Together
Read that again. Subversion 1.5 and Subversion 1.6 DO NOT play well together. If you have upgraded a client to 1.6 or the server to 1.6 and you still have 1.5 out there lingering, you are going to run into some compatibility issues. You are going to run into errors like I described above.
When the client is upgraded and the server is not, you are going to see conflicts that you cannot physically resolve. You are also going to get issues with trying to resolve the tree conflicts you can resolve because the server is confused. I ran into these types of errors. Most of you will upgrade your clients and possibly run into this as well.
"Error: Aborting commit: 'C:\SVN\source-branch\src\item.vssscc' remains in conflict " and the file is gone. It's just gone!
I was able to resolve everything except for the case where a file was deleted both from the branch and the mainline. During the merge there was no file I could click on to resolve the conflict and there wasn't a way to resolve the issue otherwise. I pulled my hair out trying to figure this out. Then I started searching. I probably should have started there. If you look at the comments in Paul Barba's Submerged article (CollabNet Subversion Blog):
Hi Rob,
I just wrote a long response, but then something occurred to me: What version of TortoiseSVN are you using? I haven't downgraded to check exactly what happens, but if you are not using TortoiseSVN 1.6+ then you will definitely have problems with tree conflicts if you are using a 1.6+ command line client.
See http://tortoisesvn.tigris.org/tsvn_1.6_releasenotes.html#compatibility.
Of course if you *are* using TortoiseSVN 1.6+ then let me know and we can go from there.
Paul
What I missed originally is that Paul is talking about TortoiseSVN as the server. I use VisualSVN Server for the server in source control. He hadn't downgraded to see what the issue is, but I know from experience (and a couple of long and painful merge processes), it's a bear!
When the server is upgraded and the client is not, its possible everything is going to look okay locally and you won't be able to commit due to a tree conflict. This is pretty scary as well! Imagine the frustration when everything looks fine and you can't commit! Note: I haven't actually verified this side, it's more theory. If you have had this experience or not, please comment. It's possible this scenario will work appropriately (see http://tortoisesvn.tigris.org/tsvn_1.6_releasenotes.html#tree-conflicts).
Update (this is not verified, but approximately how I came into this problem):
If you want to learn more about this issue, try this:
1. Ensure your server is running version 1.5.
2. Create a branch of the trunk.
3. Now upgrade your client tools to 1.6.
4. Start working in the trunk of a repository.
5. Delete a file in the trunk. Commit.
6. Delete the same file in the branch. Commit.
7. Merge up from the trunk to the branch.
8. Try to commit.
Recommendation
Wait until you can upgrade both the client and the server (and usually it's the server that is waiting for the upgrade) before you migrate to Subversion 1.6. Otherwise you might run into some weird issues. And not issues you can resolve before a commit!
Did you enjoy this article?
Subscribe for more updates!