skip to primary navigationskip to content

Resolving conflicts

For more details on using Subversion visit the Subversion online instruction book.

Occasionally, you will get a conflict when you update files from the repository.
This occurs when two or more authors have changed the same lines of a file.

Suppose you run svn update and you get the following result:
	$svn update
	U	index.html
	G	changed-b.html
	C	rubbish-b.html
	Updated to revision 46.
  • U - Updated:
    file contained no local changes, but was updated from changes from the repository
  • G - Merged:
    file had local changes, but the changes from the repository didn't overlap with the local changes.
  • C - Conflict:
    changes from the server overlaps with your own and you need to manually choose between them.

Whenever a conflict occurs, three things happen to alert and assist you in resolving it:

  1. Subversion prints a C during update, as shown in the example above.
  2. Conflict markers are placed in the file to visibly demonstrate the conflicting areas:
    <<<<<<< filename
        your changes
        code merged from repository
    >>>>>>> revision
  3. For every conflicted file, Subversion places three additional files in your directory:

    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 your latest changes in it and nothing else.
    (If Subversion considers the file to be unmergable, then the .mine file isn't created, since it would be identical to the working file).

    filename.ext.r1 #old revision
    This is the file that was the BASE revision before you updated your working copy.
    That is, it is the file that you checked out before you made your latest edits.

    filename.ext.r2 #new revision
    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.

For example, Sally makes changes to the file changedfile-b.html 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:

	$svn update
	C 	changedfile-b.html
	Updated to revision 2
	$ls -l
At this point, Subversion will not allow you to commit the file changedfile-b.html until the three temporary files are removed.
	$svn commit -m "your comments" <filename>
	svn: Commit failed (details follow):
	svn: Aborting commit: "/home/sally/cl-preview/changefile-b.html" remains in conflict

To fix this, you need to do one of three things:

You must run svn resolved when finished
This removes the three temporary files and tells subversion the file is no longer in conflict.

Merging Conflicts by Hand

The "<<<<<<<", "=======" and ">>>>>>>>" signs are conflict markers.
(You need to make sure you have removed these signs before you commit the file).

The following is an example of a conflicting file with Conflict Markers.

	$ cat sandwich.txt
	Top piece of bread
	<<<<<<< .mine
	Grilled Chicken
	>>>>>>> .r2
	Creole Mustard
	Bottom piece of bread
  • The text between "<<<<<<< .mine" and "=======" is the original text, indicated by the .mine
    	<<<<<<< .mine
  • The text between "=======" and ">>>>>>>>" is the new conflicting text, indicated by the .r2
Don't just delete the text!
Go and talk to the original author to agree on what the final edition should read.
Once the changes are agreed,

Copying a file onto your working file

If you get a conflict and decide that you want to throw our all your changes, you can copy one of the temporary files created by Subversion over the file in your working copy:

	$svn update
	C changedfile.html
	Updated to revision 2
	$ls changedfile.*
	changedfile.html changedfile.html.mine changedfile.html.r2 changedfile.html.r2
	$cp changedfile.html.h=r2 changedfile.html
	$svn resolved changedfile.html