[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 3056]  avoid repeat merge in an intelligent way
From:       pburba () tigris ! org
Date:       2010-10-28 15:22:03
Message-ID: 20101028152203.43C12540134 () sc157-tigr ! sjc ! collab ! net
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=3056



User pburba changed the following:

                What    |Old value                 |New value
================================================================================
                      CC|'pburba'                  |'cmpilato,pburba'
--------------------------------------------------------------------------------
                  Status|NEW                       |RESOLVED
--------------------------------------------------------------------------------
              Resolution|                          |DUPLICATE
--------------------------------------------------------------------------------




------- Additional comments from pburba@tigris.org Thu Oct 28 08:22:01 -0700 2010 -------
This core of this issue is the same as that for issue #2837 'Allow merge
tracking to be useful when performing cyclic merging', and that is this:

A revision is the smallest unit which merge tracking "tracks".

For those who don't want to dig through the referenced threads or the attached
script, here is as simple a demonstration of the problem as I can imagine:

Given this repository (assume the text edits in r5 and r6 are conflicting):

trunk----------text----------------------------clean------------->
  r1   |       edit                            merge of r5
       |       foo.c                           from vendor
      copy      r4                               r8
       |                                          ^
       V                                          |
    +branch-------------text-----merge r5---------|-------------->
      r3                edit     from vendor      |
                        bar.h    manually         |
                         r6      resolving        |
                                 conflict         |
                                   r7             |
                                   ^              |
                                   |              |
  vendor--------------text----------------------------->
  branch              edit
  import              bar.h
    r2                r5

Now say we want to sync ^/branch with ^/trunk, we'd try this merge:

  svn merge ^/trunk branch

There have been no merges between trunk and branch, so all changes since the
branch point are eligible.  The only operative ones are r4 and r8.

But wait...the merge source and target share some common history from a 3rd
unrelated branch:

  Properties on 'trunk':
    svn:mergeinfo
      /vendor:5
  Properties on 'branch':
    svn:mergeinfo
      /vendor:5

So both the merge source and the target have r5 from the vendor branch.  But of
course these mean quite different things!

On trunk, r5 was cleanly merged from ^/vendor, so the text changes to bar.h in
r5 and r8 are the SAME.

On ^/branch there was a conflict which we manually resolved in r7, so the text
changes to bar.h in r5 and r7 are DIFFERENT.

Here is where the 'A revision is the smallest unit which merge tracking tracks'
problem arises. Revision 7 and revision 8 are different changes, but we
represent them the same way in mergeinfo, namely as '/vendor:5'.  So when we
attempt the merge, we get a conflict:

  >svn merge ^/trunk branch
  --- Merging r3 through r8 into 'branch':
  U    branch\foo.c
  Conflict discovered in 'branch/bar.h'.
  Select: (p) postpone, (df) diff-full, (e) edit,
          (mc) mine-conflict, (tc) theirs-conflict,
          (s) show all options: p
  C    branch\bar.h
   G   branch
  Summary of conflicts:
    Text conflicts: 1

Now let's be clear here, this is not a problem new to merge tracking, it's
always been a "limitation" of Subversion; if we did the merge 'svn merge -c8
--ignore-ancestry ^/trunk branch' we'd get the same conflict.

Now we could improve merge tracking so that it realizes that r8 on ^/trunk was
created as a merge of r5 from ^/vendor and that history is already part of
^/branch per its mergeinfo, so we can skip merging r8 altogether (I believe this
was basically Folker's original point in the thread referenced in desc1).  

But wait, what if r8 on ^/trunk included changes in addition to the merge of r5?
 Hardly best practice I know, but regardless, this approach would lose those
changes, because, you guessed it, we are right back at the 'A revision is the
smallest unit which merge tracking tracks' problem and since *that* is what
issue #2837 is really about, I am marking this as a duplicate of #2837.


*** This issue has been marked as a duplicate of 2837 ***

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2676773

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]