You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Apache subversion Wiki <co...@subversion.apache.org> on 2013/09/03 11:13:45 UTC

[Subversion Wiki] Update of "KeepingReintegratedBranchAlive" by JulianFoad

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "KeepingReintegratedBranchAlive" page has been changed by JulianFoad:
https://wiki.apache.org/subversion/KeepingReintegratedBranchAlive?action=diff&rev1=7&rev2=8

- See "Keeping a Reintegrated Branch Alive" in the Svn Book here: http://svnbook.red-bean.com/en/1.6/svn-book.html#svn.branchmerge.advanced.reintegratetwice.
+ ''The section on keeping a reintegrated branch alive became obsolete with the release of Subversion 1.8.''
+ 
+ ----
+ = Keeping a Reintegrated Branch Alive =
+ A discussion on ways to improve the user experience when trying to keep using a branch after reintegrating it.  This was a problem from Subversion 1.5 through Subversion 1.7.  See "Keeping a Reintegrated Branch Alive" in the Subversion 1.6 Book here: http://svnbook.red-bean.com/en/1.6/svn-book.html#svn.branchmerge.advanced.reintegratetwice.
  
  == Simple Use Case ==
  Here's a diagram showing a typical feature-branch work flow and the step we want to eliminate.
- 
  ||Rev ||A ||B ||Commit ||
  ||r10 ||X || || ||
  ||r20 || ||X ||New branch B from A ||
@@ -15, +18 @@

  ||r60 || ||M ||Sync merge A to B ||
  
  
- The sync merge r60 should take r50 but not r40.
+ 
+ 
+ The sync merge r60 should "take" the change r50 from A, but not r40. Subversion client versions 1.5 through 1.7 don't merge correctly at r60 without extra help such as that provided by the r45 commit.
  
  == Ways to make it easier ==
  (in order from easiest to implement to best for the user):
@@ -51, +56 @@

  
   * Make the "sync merge" code recognize the reintegration revision without having to record-only it on the branch. Either store a special marker in the svn:mergeinfo at reintegrate time, or deduce the fact at sync-merge time. Difficult I know.
  
+ Subversion 1.8 implements a solution superior to any of the above.  The enhancement is announced [[http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate|in the 1.8 release notes]] and some design notes are in the [[SymmetricMerge|Symmetric Merge]] Wiki page.
+ 
+ ----
+ = Complex Merging =
- == Complex Use Case ==
+ == Complex Merge Use Case ==
  In the final sync merge in this more general use case, the interesting question is what to do with r11.
+ 
+ (This question is based on the premise that the merge from A to A_COPY will be executed by selecting a set of revisions along the direct history of branch A, and merging them to branch A_COPY.  This is what the merge algorithm does in Subversion v1.5 through at least v1.8 (except when reintegrating).  A different merge algorithm might be needed to handle this scenario well.)
  
  {{{
  A@1---r4---r5---r6---r7----------------r11----------->