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
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
Subversion prints a
during the update, and remembers that the file is in a
state of conflict.
If Subversion considers the file to be mergeable, it
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:
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.)
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
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
OLDREV is the revision number
of the file in your
NEWREV is the revision number of
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.
$ svn resolved sandwich.txt Resolved conflicted state of 'sandwich.txt'
 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.