merge-tracking.txt

linux subdivision ying gai ke yi le ba

                       Merge-Tracking in Subversion
                       ============================

These notes try to break apart the various sub-problems of
"merge-tracking".  People can mean a whole lot of different things
when they utter that phrase, so this is an attempt to describe various
aspects.

This is NOT a design document.  It offers no solutions or proposals.
It's just a place to enumerate potential problems that need solving.

[At the moment, implementing locking is higher priority;  but I wanted
to document these problems here so we don't forget them.]


A.  Solve the "repeated merge" problem at the level of whole changesets.

      Track which changesets have been applied where, so users can
      repeatedly merge branchA to branchB without having to remember
      the last range of revisions ported.  This would also track
      "changeset cherry-picking" done by users, so we don't
      accidentally re-merge changesets that are already applied.

      This is the problem that svk and arch claim to have already
      solved, what they're calling "star-merge".  Need to investigate
      how they're doing it, might be a good precedent to imitate.

B.  Make 'hunks' of contextually-merged text sensitive to ancestry.

      This is like a high-resolution version of problem #1.  Rather
      than tracking whole changesets, we track the lineage of specific
      lines of code within a file.  The basic idea is that when
      re-merging a particular hunk of code, the contextual-merging
      process is aware that certain lines of code already represent
      the merging of particular lines of development.  Jack Repenning
      has a great example of this from Clearcase, which we can draw in
      this space.  See diagram at the bottom for an explanation.

      See ../www/variance-adjusted-patching.html for an extended
      discussion of how to implement this by composing diffs; see
      svn_diff_diff4() for an implementation of same.  We may be
      closer to ancestry-sensitive merging than we think.

C.  'svn merge' needs to track renames better.  

     Edit foo.c on branchA.  Rename foo.c to bar.c on branchB.

     1. Try merging the branchA edit into a working copy of branchB:
        'svn merge' will skip the file, because it can't find it.

     2. Conversely, try merging branchB rename to branchA: 'svn merge'
        will delete the 'newer' version of foo.c and add bar.c, which
        has the older text.

     Problem #2 stems from the fact that we don't have true renames,
     just copies and deletes.  That's not fixable without an fs schema
     change and (probably) a libsvn_wc rewrite.

     It's not clear what it would take to solve problem #1.

     See http://www.contactor.se/~dast/svn/archive-2004-07/0084.shtml
     about our rename woes and the relationship to merge tracking.


---------------------------------------------
Here's an example of problem B above, demonstrating how individual
lines of code can be "merge tracked".  

In this diagram, we're drawing the lineage of a single file, with time
flowing downwards.  The file begins life with three lines of text,
"1\n2\n\3\n".  The file then splits into two lines of development.

                                 
                          
                    1     
                    2     
                    3     
                  /   \   
                 /     \  
                /       \ 
            one           1   
            two           2.5 
            three         3   
             |     \      |
             |      \     |   
             |       \    |            
             |        \   |            
             |         \ one                ## This node is a human's
             |           two-point-five     ## merge of two sides.
             |           three        
             |            |
             |            |
             |            |
            one          one
            Two          two-point-five
            three        newline       
               \         three  
                \         |   
                 \        |
                  \       |
                   \      |
                    \     |
                     \    |
                      \   |
                       \  |
                         one                ## This node is a human's
                         Two-point-five     ## merge of the changes
                         newline            ## since the last merge.
                         three
                              

It's the second merge that's important here.  

In a system like Subversion, the second merge of the left branch to
the right will fail miserably: the whole file's contents will be
placed within conflict markers.  That's because it's trying to dumbly
apply a patch that changes "1\n2\n3" to "one\nTwo\nthree", and the
target file has no matching lines at all.

A smarter system (like Clearcase) would remember that the previous
merge had happened, and specifically notice that the lines "one" and
"three" are the results of that previous merge.  Therefore, it would
ask the human only to deal with the "Two" versus "two-point-five"
conflict; the earlier changes ("1\n2\n3" to "one\ntwo\nthree") would
already be accounted for.