Subversion 1.5 – Resolving Conflicts

If you are a regular reader of this blog then you are undoubtedly aware that Subversion 1.5 will be coming out later this year and that the big feature is merge tracking. Technically, merge tracking is a largely internal feature with the exception of the ways in which it simplifies the overall UI of the merge process. Implementing this feature has caused us to spend a lot of time just thinking about the entire merge process and this has led to some additional improvements that are not technically part of the merge tracking feature. That brings us to what this post is about and that is how Subversion 1.5 will make it easier than ever for you to resolve conflicts.

There are two specific enhancements that are coming in Subversion 1.5 that are related to resolving conflicts. The first is that the svn resolved command was enhanced to include a new –accept option that lets you mark a conflict as resolved by choosing a specific version of a file and the second is a feature we call interactive conflict resolution.

svn resolved

When Subversion generates a conflict in a file, you have to take some kind of action to resolve the conflict and then run the svn resolved command to tell Subversion that you did so. As stated previously, this command now has an –accept option that allows you to mark the conflict as resolved and also choose a specific version of the file at the same time. The most obvious use for this feature is with binary files.

An example where I know I will use this feature is when I have a release branch that is using a different version of a binary, such as a JAR file, than my trunk. For example, my branch might be using the 1.x version of some library and trunk is using 2.x. When I backport changes from trunk to the branch and I include revisions that updated the libraries, I get conflicts in my branch. Without this command, I would have to manually copy/rename the correct version of the file in my working copy, and then run the svn resolved command. With this enhancement, I can now just tell Subversion to do this for me. For example:

svn resolved –accept=left my-library.jar

This would resolve the conflict taking the version of the file that was already being used in the branch. Besides binary files, other users commented they would use this in scripts that are doing automated merges to certain branch types. Obviously this feature is not designed to deal with scenarios where you need to use a 3-way diff/merge tool to resolve the conflicts line by line. However, the next feature I want to talk about does cover that scenario.

Interactive Conflict Resolution

The development of the svn resolved feature really got the developers thinking about how this sort of feature could be integrated into the merge process itself (by the way: both of these features also apply to the update and switch commands as they can also generate conflicts). This led to the creation of the interactive conflict resolution feature. Here is an example of the feature:

    svn up
    U    contrib/client-side/svnmerge/svnmerge_test.py
    Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
    Select: (p)ostpone, (d)iff, (e)dit, (h)elp : h
      (p)ostpone - mark the conflict to be resolved later
      (d)iff     - show all changes made to merged file
      (e)dit     - change merged file in an editor
      (r)esolved - accept merged version of file
      (m)ine     - accept my version of file
      (t)heirs   - accept repository's version of file
      (l)aunch   - use third-party tool to resolve conflict
      (h)elp     - show this list

    Select: (p)ostpone, (d)iff, (e)dit, (h)elp : t
    G    contrib/client-side/svnmerge/svnmerge.py
    Updated to revision 25685.

In this example, I was running the update command and it encountered conflicts because I had local changes to a file that I needed to commit. The update process prompted me to resolve the conflict and also gives me a lot of different options to assist me. In this example, I took the (h)elp option to show some of the more advanced options that are available. For example, as with the svn resolved feature, I can choose to just select a specific version of the file (again useful for binary file types), but now I can also choose to see a diff, or open an editor or even launch a 3-way diff tool. The latter two options require an environment variable named EDITOR or SVNMERGE to be set with the tool to launch.

If you take the option to edit the file, when you are finished, you can just indicate to Subversion that you have resolved the conflicts. In this case, the file is never marked as conflicted in the working copy and does not need to be resolved later. Note that you can also just use the (p)ostpone option if you want Subversion to just mark the file as conflicted in which case you can resolve it later, as you would today.

There are a couple of ways you can turn off this feature. The first is to add the –non-interactive option to the command when you run it. With this option set, Subversion will just create conflicts and not prompt you during the process. This is useful for automated scripts or one-offs when you just do not want to be prompted. You can also turn this feature off globally by editing the runtime configuration file and setting this option:

     [miscellany]
     interactive-conflicts = no

With this setting in your configuration file, you essentially have the pre-1.5 behavior.

Conclusion

Something I did not touch on yet is that both of these features are available in the Subversion API, so graphical clients will be able to easily implement the same features. For example, I have already integrated all of the interactive conflict resolution into the CollabNet Desktop – Eclipse Edition. As we get closer to the release date for Subversion 1.5, I will probably do another post that shows some of the features from the perspective of our graphical client for Subversion. Likewise, I am sure that TortoiseSVN will integrate these features soon and will do some great things with this.

Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

Tagged with: , , , , , , , , ,
Posted in Subversion
8 comments on “Subversion 1.5 – Resolving Conflicts
  1. One thing that bothers me is why the heck “–acept=left” and not “–accept=my”? The latter looks just more intuitive to me. Anyway, I can’t really wait to have Subversion 1.5 installed on our server and see the new features in Subclipse at the same time. 🙂
    -Gunnar

  2. I am fairly certain that there were aliases added. So you can say mine or left, theirs or right, base or working. Something like that.
    The feeling was that the commonly used left/right that you see in a 3-way diff always somewhat applies but mine/theirs does not apply to well to merges, only updates.
    You’d have to read the mailing list threads to see the various opinions that were espoused.
    Mark

  3. Kim Sullivan says:

    I recently started to use svk, and the interactive conflict resolution really comes in handy, I’m glad it will be supported by svn (and “mine” certaily is better than “yours”… generally the description seems to be much easier to understand). I’m really looking forward do this.

  4. Niall Gallagher says:

    This looks really interesting, in particular I think the addition of such a feature will really help the Eclipse Subversion integration, which in its current state is not really great.
    I was recently asked to review a migration from CVS to Subversion, however for our process Eclipse and CVS was just way ahead in terms of its capability to deal with our required merge scenarios. I hope the interactive capabilities for 1.5 will be adopted by Subclipse so that we can finally dump CVS 🙂

  5. rmurphy440m says:

    Would it be possible to have a switch to turn off auto-merging entirely? With our code base merging almost ALWAYS results in a conflict and when it does work I am nervous about using the code that it produces. We use the lock feature exclusively but it would be nice to prevent an accidental merge here or there.

  6. Harlan Rosenthal says:

    Second the motion: switch to turn off auto-merging. I would rather see a conflict if there were ANY change locally. Like the previous poster, I have seen auto-merging cause errors – understandable from the text standpoint, but fatal from the hardware standpoint.

  7. Cagatay says:

    I am implementing an eclipse IDE plug-in which provides subversion support for eclipse users. I want to put marker on appropriate lines when conflicts are occured. But I can’t find any solution yet. Is it possible to get conflicted lines number in svn?
    (By the way I use javaHL with SVNClientAdapter)

  8. No, there is no API for this. Subversion inserts its own markers in the code. You could probably search them out and add/replace them with your own.
    Any reason you are not just basing your plug-in on Subclipse? Or contributing the additional features you need?

Leave a Reply

Your email address will not be published. Required fields are marked *

*