|
Version Control with Subversion - Basic Work Cycle - Resolve Conflicts (Merging Others' Changes)
Resolve Conflicts (Merging Others' Changes)
We've already seen how
svn status -u
can predict conflicts. Suppose you run
svn
update
and some interesting things occur:
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
The U and
G codes are no cause for
concern; those files cleanly absorbed changes from the
repository. The files marked with
U contained no local changes
but were Updated with changes
from the repository. The G
stands for merGed, which
means that the file had local changes to begin with, but the
changes coming from the repository didn't overlap with the local
changes.
But 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.
Whenever a conflict occurs, three things typically occur
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 of a mergeable
type, 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 “svn:mime-type” to learn more.)
-
For every conflicted file, Subversion places up to
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 your
latest changes in it and nothing else. (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:
$ svn update
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 you to commit the file sandwich.txt
until the three temporary files are removed.
$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict
If you get 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.[5]
$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'
[an error occurred while processing this directive]
|
