| Here are two general schemes for solving the repeated merge problem: |
| |
| The Most Recent Common Ancestor approach (MRCA) |
| ----------------------------------------------- |
| |
| In this scheme, you record an optional set of merge sources in each |
| node-revision. When asked to do a merge with only one source (that |
| is, just "svn merge URL", with no second argument), you compute the |
| most recent ancestor and do a three-way merge between the common |
| ancestor, the given URL, and the WC. |
| |
| To compute the most recent ancestor, you chain off the immediate |
| predecessors of each node-revision. The immediate predecessors are |
| the direct predecessor (the most recent node-revision within the node) |
| and the merge sources. An interleaved breadth-first search should |
| find the most recent common ancestor. |
| |
| The Ancestry Set approach (AS) |
| ------------------------------ |
| |
| (For a longer description of this approach, see |
| http://svn.collab.net/repos/svn/trunk/doc/programmer/design/model.texi |
| under "Merging and Ancestry".) |
| |
| In this scheme, you record the full ancestry set for each |
| node-revision--that is, the set of all changes which are accounted for |
| in that node-revision. (How you store this ancestry set is |
| unimportant; the point is, you need a reasonably efficient way of |
| determining it when asked.) If you are asked to "svn merge URL", you |
| apply the changes present in URL's ancestry but absent in WC's |
| ancestry. Note that this is not a single three-way merge; you may |
| have to apply a large number of disjoint changes to the WC. |
| |
| Comparisons and arguments |
| ------------------------- |
| |
| AS allows you to merge changes from a branch out of order, without |
| doing any bookkeeping. MRCA requires you to merge changes from a |
| branch in order. |
| |
| Consistency with other modern version controls systems is desirable. |
| |
| MRCA may be simpler to implement, since it results in a single |
| three-way merge. |
| |
| MRCA may be easier for users to understand, even though AS is probably |
| simpler to a mathematician. |
| |
| MRCA may break down faster if the merging topology is not |
| hierarchical. |
| |
| An Open Question (applying to both schemes) |
| ---------------- |
| |
| If a user asks to merge a directory, should we apply MRCA or AS to |
| each subdirectory and file to determine what ancestor(s) to use? Or |
| should we apply MRCA or AS just once, to the directory itself? The |
| latter approach seems simpler and more efficient, but will break down |
| quickly if the user wants to merge subdirectories of a branch in |
| advance of merging in the whole thing. |