Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know

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!

image

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?

kick it on DotNetKicks.com     Subscribe for more updates!

Print | posted @ Wednesday, June 10, 2009 6:26 AM

Comments on this entry:

Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Ordinant at 6/10/2009 2:32 PM

I'm afraid you misread Paul Burga's response to you in the link you cite, and as a result, you got things pretty much wrong.

There is no server version of Tortoise. TortoiseSVN is an SVN client. Paul was asking if you had mixed 1.5 and 1.6 versions of two clients, Tortoise and a command-line client such as Cygwin's. The version of the server just did not come up.

The bottom line is clearly stated in the Subversion 1.6 release notes: "Older clients and servers interoperate transparently with 1.6 servers and clients."

The notes go on to warn that you should not mix different releases of Subversion CLIENTS on the same checkout. That was true when 1.5 came out, and it's true again for 1.6. For a given working directory checked out from ANY version server, make sure all your SVN clients are at the same revision level. For Windows, that includes command-line svn from Collabnet, command-line svn from Cygwin, and TortoiseSVN: make them all 1.5 or all 1.6 and everything will be fine.
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Robz at 6/10/2009 9:28 PM

@Ordinant: I hope you don't mind, I am going to respond to each part of your comments. I think we can both learn something valuable as a result and I want to keep an open dialog.

"I'm afraid you misread Paul Burga's response to you in the link you cite, and as a result, you got things pretty much wrong."

I would agree with you here, except that Paul was super responsive, and if I was wrong, the next few lines in the comments where I mentioned we only use TortoiseSVN as a client he would have corrected. This is what I said: "Oh wait. Rereading... I misread b/c I use TortoiseSVN only as a client tool. We use VirtualSVN Server in the back end and it is not upgraded." So it looks like I read his response right.


"There is no server version of Tortoise. TortoiseSVN is an SVN client."

You are absolutely correct, there is no server version of Tortoise. TortoiseSVN itself can create repositories! Try it. Create a folder on your desktop. Then right click on that folder and select [TortoiseSVN]->[Create repository here]. It's cool. Most people don't know you can do that.


"Paul was asking if you had mixed 1.5 and 1.6 versions of two clients, Tortoise and a command-line client such as Cygwin's. The version of the server just did not come up."

Once again, that is what I thought at first, until I reread his comments. I realized that he meant to check if I was using TortoiseSVN to create and maintain repositories and command line to work with the working copy of the repository. In other words a server on 1.5 and a client on 1.6.


"The bottom line is clearly stated in the Subversion 1.6 release notes: 'Older clients and servers interoperate transparently with 1.6 servers and clients.'"

Even Paul himself admits to not downgrading to check to see what happens.


"The notes go on to warn that you should not mix different releases of Subversion CLIENTS on the same checkout. That was true when 1.5 came out, and it's true again for 1.6. For a given working directory checked out from ANY version server, make sure all your SVN clients are at the same revision level. For Windows, that includes command-line svn from Collabnet, command-line svn from Cygwin, and TortoiseSVN: make them all 1.5 or all 1.6 and everything will be fine."

Agreed. In fact, you can't mix them. One of the clients will complain that it can't do anything because it can't work with a 1.6 working copy. My error was nothing close to this and Paul, being part of the Subversion team, would have understood that wasn't my problem immediately.

Because I was accessing the directory with both client tools (TortoiseSVN and command line), they were both in sync. But Paul didn't know that when he commented. That is when it became clear to me that Paul was talking about me using TortoiseSVN as the repository tool (aka server).

If you want to learn more about this issue, try this:
1. Ensure your server is running version 1.5.
2. Now upgrade your client tools to 1.6.
3. Start working in the trunk of a repository.
4. Create a branch of the trunk.
5. Delete a file in the trunk.
6. Delete the same file in the branch.
7. Merge up from the trunk to the branch.
8. Good luck ever getting that issue resolved!

This issue has been seen by others. That was why I decided I needed to post on it.
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by alberto at 6/29/2009 6:31 AM

I have followed your example step by step and I just had to mark the conflict as resolved. The conflict remains in svn (server) 1.6, same resolution.
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Robz at 6/29/2009 3:32 PM

alberto: Rock!
I am starting to think this is related to branching when everything was 1.5 and then upgrading client tools to 1.6.

Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by J Pihl at 6/30/2009 6:34 AM

Tried just merging a branch and a trunk to branch(to make branch up to date) where a login dir has been created in both. It just deletes login dir in branch without NO error messages. Sure it say tree conflict but then it deletes everything :-(
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Jeroen at 8/6/2009 9:45 AM

Is this also an issue with a SVN 1.3 or 1.4 server and SVN 1.6 clients. I never have encountered such issue, but I suppose tree conflicts are rather seldom.
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Niall Brown at 9/16/2009 8:31 AM

So you have correctly identified the issue. Yes, this has happen for a repository I work with. The bigger question is how to find an appropriate resolution to the problem for example, would upgrading all to 1.6 actually clear the conflicts experienced during a merge.

N.
Gravatar # re: Subversion 1.6, Tree Conflicts, and the Incompatibility of Subversion 1.5: What You Need to Know
by Robz at 9/17/2009 1:13 PM

The branch for me was created before the upgrade. So it kept trying to merge from Rev1 all the way up for a repo with a ton of commits. I started paying attention to the last time I merged and starting from there in the merge dialog.
Comments have been closed on this topic.