Postponing Conflict Resolution

This may sound like an appropriate section for avoiding marital disagreements, but it's actually still about Subversion, so read on. If you're doing an update and encounter a conflict that you're not prepared to review or resolve, you can type p to postpone resolving a conflict on a file-by-file basis when you run svn update. If you're running an update and don't want to resolve any conflicts, you can pass the --non-interactive option to svn update and any file in conflict will be marked with a C automatically.

The C stands for conflict. This means that the changes from the server overlapped with your own, and now you have to manually choose between them after the update has completed. When you postpone a conflict resolution, svn typically does three things to assist you in noticing and resolving that conflict:

  • Subversion prints a C during the update, and remembers that the file is in a state of conflict.

  • If Subversion considers the file to be mergeable, it places conflict markers—special strings of text which delimit the “sides” of the conflict—into the file to visibly demonstrate the overlapping areas. (Subversion uses the svn:mime-type property to decide if a file is capable of contextual, line-based merging. See the section called “File Content Type” to learn more.)

  • For every conflicted file, Subversion places three extra unversioned files in your working copy:

    filename.mine

    This is your file as it existed in your working copy before you updated your working copy—that is, without conflict markers. This file has only your latest changes in it. (If Subversion considers the file to be unmergeable, then the .mine file isn't created, since it would be identical to the working file.)

    filename.rOLDREV

    This is the file that was the BASE revision before you updated your working copy. That is, the file that you checked out before you made your latest edits.

    filename.rNEWREV

    This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.

    Here OLDREV is the revision number of the file in your .svn directory and NEWREV is the revision number of the repository HEAD.

For example, Sally makes changes to the file sandwich.txt in the repository. Harry has just changed the file in his working copy and checked it in. Sally updates her working copy before checking in and she gets a conflict, which she postpones:

$ svn update
Conflict discovered in 'sandwich.txt'.
Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : p
C  sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

At this point, Subversion will not allow Sally to commit the file sandwich.txt until the three temporary files are removed.

$ svn commit -m "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict

If you've postponed a conflict, you need to do one of three things:

  • Merge the conflicted text “by hand” (by examining and editing the conflict markers within the file).

  • Copy one of the temporary files on top of your working file.

  • Run svn revert <filename> to throw away all of your local changes.

Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.[6]

$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

[6] You can always remove the temporary files yourself, but would you really want to do that when Subversion can do it for you? We didn't think so.

Prev Up Next
Resolving Conflict Differences Interactively Home Merging Conflicts by Hand