A tree conflict appears in fcm status like this:
! C subroutine/hello_sub_dummy.h
> local missing, incoming edit upon merge
and can require complex action to solve, based on the situation. Happily,
fcm conflicts automates the resolution of most ordinary tree
conflicts.
This page is intended to give more information about the meaning of the common tree conflicts, and to give guidance on those that aren't handled automatically, such as directory tree conflicts.
The list below is ordered by output from fcm status. There
are two choices that the user must make:
fcm
conflicts.fcm
conflicts.For example, if you are merging the trunk into a working copy of a branch, keep local would refer to keeping the changes as they existed on the branch; discard local would refer to accepting the trunk changes and discarding the branch ones.
In this page, we use the word local for your local working copy, and external for the outside source you are updating or merging in from. In the example above, local would mean your working copy of the branch; external would mean the trunk.
Subversion implements rename as a copy-and-delete operation. This means a rename can show up as a delete (or missing) in the tree conflict information.
It's very important to find out if your tree conflict arises from a
rename, but this information has to be dug out of fcm log. A
rename can have occurred locally or externally. An external rename would show
up in fcm status as an addition with history (A
with +): for example:
A + FILENAME
fcm log -v FILENAME can be used to examine if this is really
just a rename - it will show up as FILENAME (from ORIGINAL_FILENAME).
Local renames that have been committed won't show up in fcm
status. These can still be found using fcm log -v for
each filename, or you can try to remember what happened!
This section contains specific help on different types of tree conflict.
Find the relevant section below by running fcm status and
looking up the information below the file in conflict - e.g.:
! C subroutine/hello_sub_dummy.h
> local delete, incoming delete upon merge
in this case the local delete, incoming delete upon merge is the correct section header.
There are some situations not covered below - local obstruction is not covered here, as it is a case of the user corrupting the working copy - try a new checkout. Similarly, local unversioned is just a case of a problem with something in the working copy - an unversioned file or directory exists where Subversion wants to put the new stuff. Delete or move it, and try the merge again.
If you know that a rename has happened, use the (renaming) suffix for your section below. Otherwise, choose the (no renaming) suffix.
fcm resolve always takes the form fcm resolve --accept
working FILENAME for tree conflicts.
what it means: files or directories added with the same name independently
what keep local does: uses rename to shuffle the old file
to a different name, copies the new file in, renames the new file to the
original name but with a temporary-style suffix (e.g. hello.F90 ->
hello.F90.xD4r), and again renames the old file to the original name.
(Then runs fcm resolve).
what discarding local does: renames the old file to give it
a temporary-style suffix (e.g. hello.F90 -> hello.F90.r6Ys), and
copies the new file into the original name. (Then runs fcm
resolve).
meaning: file or directory modified on the branch locally, but deleted on the merge branch
what keep local does: just runs fcm
resolve.
what discarding local does: deletes the file or directory
and runs fcm resolve.
meaning: file modified on branch locally, but renamed on merge branch
what keep local does: copies over the renamed file, and the
common ancestor of the file on the branches, and uses them for a text
conflict style merge into the old (local) filename. It then removes the
renamed file and runs fcm resolve.
what discarding local does: copies over the renamed file,
and the common ancestor of the file on the branches, and uses them for a
text conflict style merge into the new renamed file. It then deletes the
old file and runs fcm resolve.
meaning: file modified on branch locally, but replaced (deleted, and new file added) on merge branch
what keep local does: just runs fcm
resolve.
what discarding local does: svn delete local
file, and svn copy the incoming file into it. It then runs
fcm resolve.
meaning: same filename deleted both locally and externally.
in both cases: just runs fcm resolve.
meaning: file deleted locally, but renamed externally
what keep local does: just runs fcm
resolve.
what discarding local does: just deletes the new renamed
file and runs fcm resolve.
meaning: file renamed locally, but deleted externally
what keep local does: just runs fcm
resolve.
what discarding local does: deletes the local renamed file
and runs fcm resolve.
meaning: same file renamed locally AND externally, to two different names.
what keep local does: copies in the external file and
common ancestor file to construct a text-style merge using
xxdiff into the locally-renamed filename. Removes the
external rename and runs fcm resolve.
what discarding local does: copies in the external file and
common ancestor file to construct a text-style merge using
xxdiff into the externally-renamed filename. Removes the
local rename and runs fcm resolve.
meaning: locally deleted file, add newer file from merge branch?
what keep local does: just runs fcm
resolve.
what discarding local does: copies in the external file
using its URL and runs fcm resolve.
meaning: locally renamed file, but external changes to the old filename
what keep local does: copies in the external file and
common ancestor to construct a text-style merge using
xxdiff, into the locally-renamed filename. Runs fcm
resolve.
what discarding local does: copies in the external file and
common ancestor to construct a text-style merge using
xxdiff, into the original filename. Deletes the
locally-renamed file and adds the original filename, then runs fcm
resolve.