Changes between Version 6 and Version 7 of UsingPidginMonotone

Timestamp:

Dec 12, 2006, 2:47:20 PM (17 years ago)

Author:

elb

Comment:

--

UsingPidginMonotone

@@ -78 +78 @@
 While all of this seems somewhat complex and difficult compared to the linear-history model of CVS or svn, it is really quite unavoidable in the context of a distributed VCS (as the above example shows).  Different systems handle it differently (darcs in particular using quite a different model), but the problem will exist in any such system.  Once you get your head wrapped around it, it's actually quite intuitive and powerful.  For more information, see the [http://venge.net/monotone/docs/Branching-and-Merging.html Branching and Merging] chapter of the monotone documentation.
 
+== Merging and Conflicts ==
+
+As we mentioned above, merges are generally handled with {{{mtn propagate}}} and {{{mtn merge}}}, depending on whether the merge in question is of a macro- or micro-branch.  An important, related question is, "What happens when there are conflicts?".  The answer happens to be a bit suboptimal at the moment, but the monotone folks are working on that.
+
+=== Content Conflicts ===
+
+A content conflict is when two revisions have edited the same file in close enough proximity that their diffs interfere with each other.  These cause {{{<<<<<}}} {{{=====}}} {{{>>>>>}}} blocks in CVS and Subversion.  In monotone, merges via the working directory are not yet supported; all conflicts must be resolved at merge time, and the resulting resolution will be directly committed to the revision database with no chance to edit anything else (for example, to resolve non-content-conflict logical consistency problems).  These content conflicts will be presented to you, one at a time, in a 3-way merge application.  This means that you'll have to have such an application installed; I have found that ''xxdiff'' and ''meld'' are more intuitive than some of the other options which monotone understands (such as emacs and vim merge modes).  These applications will show you the two sides of the merge conflict and the least common ancestor (the "closest" revision to the conflicting revisions, by revision hop count, computed via some clever algorithm) in separate panes, and you simply choose which stanzas you wish to include and which you wish to leave out, and make any necessary edits to make that happen.  This is a little bit tricky, but once you've done it a couple of times it becomes easier.
+
+=== Non-Content Conflicts ===
+
+A non-content conflict is a conflict not between the ''contents'' of files in two revisions, but between the files themselves.  This happens, for example, if you create a file named {{{foo.c}}} in two different revisions, and then try to merge those revisions.  It can also happen if you have files that monotone doesn't know about (like {{{.o}}} files) scattered around your build tree, and you try to merge a revision which rearranges things.  Monotone will resist removing these unknown files, which can cause conflicts if, say, the directory they are in needs to be removed or replaced.  The former type of non-content conflict can normally be resolved simply by removing or renaming the like-named files or directories in one of the revisions you wish to merge before merging.  The latter can be a bit trickier to solve (particularly because the error messages are currently rather poor and unclear), but you might find {{{mtn revert --missing}}}, {{{mtn rm --missing}}}, and {{{mtn ls unknown | xargs rm}}} helpful.  Note that all three of these remove data, and the {{{mtn rm}}} command actually changes what's in the '''repository'''.  You probably want to look at the output of {{{mtn ls missing}}} and {{{mtn ls unknown}}} before executing any of these commands.
+
 == Important Practices ==