subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "KeepingReintegratedBranchAlive" by JulianFoad
Date Tue, 03 Sep 2013 09:13:45 GMT
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:

- See "Keeping a Reintegrated Branch Alive" in the Svn Book here:
+ ''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:
  == 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
[[|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.)

View raw message