Rather than applying all of the merges ranges as a single operation,
these could be applied as a distinct set of operations, so that we don't
require a network connection to be held open for conflict resolution.
This introduces a new "partially merged" state, that indicates that
additional changes must be merged in.
Where only part of a merge could be applied, the merge halts at the
point where a conflict arises on a file. The file is marked as being
conflicted, and we note in the WC that additional merges must be applied
to the file. The conflict is resolved using exactly as conflicts are
handled in existing versions of subversion, and can take advantage of
the temporary files usually created on a conflict. When the conflict is
marked as resolved we check whether there are additional changes to be
applied, and if so we show the file state as "partially merged". This
can be resolved through the use of a "continue merge" operation, which
will apply more of the merge set, possibly raising more conflicts.
I don't understand the API enough to propose a set of functions for
this, but from the command line this might look like:
... resolve conflict somehow
svn resolved file1.c
svn merge --continue file1.c
A slight variation is to put the "--continue" option on the resolved
We would probably limit the set of operations that can be performed on a
"partially merged" file, to prevent subsequent updates from being mixed
Received on Fri Dec 1 23:06:21 2006