subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "SupportedMergeScenarios" by JulianFoad
Date Thu, 19 Jan 2012 14:19:33 GMT
Dear Wiki user,

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

The "SupportedMergeScenarios" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SupportedMergeScenarios?action=diff&rev1=4&rev2=5

Comment:
Write about merge tracking vs merging

  = What Merges Does Svn’s Merge Tracking Support? =
  We  need to be able to say, “If you do all your merging like <this>,  it will work
like you expect.”  So what is <this>?  What are the  supported scenarios, limitations
and rules, and what can the user expect  within and outside those scenarios?
  
+ The  information in this document is not intended to repeat the  functional  documentation
of the “merge” command itself, but rather to  explain the  ways in which that command
can be used effectively.
+ 
+ === Merge Tracking vs. Merging ===
  Merging  is a broad term.  We’re talking here about here merging changes that  have been
made on one branch into another branch.  The whole process of  merging includes several steps
which may be manual or automated:
  
   * selecting a source branch
@@ -15, +18 @@

   * committing the result
   * possibly  other actions such as deleting the source branch if it is finished  with, or
taking action to “keep it alive” after a reintegrate
  
- This document is concerned primarily with merging in such a way that Subversion’s merge
''tracking'' will enable future automatic (''catch-up'' and ''reintegrate) ''merges to select
the correct set of changes.  This answers the question, “What ''logical changes''  don't
I have on branch B already, that I need to pull from branch A to  B?”  A related but different
issue is how to apply those changes to the  target branch: “For a given physical or logical
change ‘c1’ that branch A  claims to have an instance of, how do I construct from ‘c1’
the best  physical edit that will apply to branch B with the least amount of  spurious physical
conflict?”
+ Merge tracking is a mechanism by which Subversion remembers which  changes you've merged
from one branch to another and uses this  information to honour a request to merge "all the
unmerged changes" from  one branch to another.  Merge tracking is about deciding which changes
to merge, and about recording which changes have been merged.  As far as merge tracking is
concerned, a "change" means the change that was committed in a particular revision to a particular
node or tree.
  
- The  information in this document is not intended to repeat the functional  documentation
of the “merge” command itself, but rather to explain the  ways in which that command can
be used effectively.
+ A related but different issue is how to apply the selected changes to the  target branch.
 The task of applying the changes to the target working copy can be called tree-merging: that
is,  taking a diff between two trees and applying this diff, node-wise and  text-wise, to
a third tree.  We could say: “For a given physical or logical change ‘c1’ that branch
A  claims to  have an instance of, how do I construct from ‘c1’ the best  physical  edit
that will apply to branch B with the least amount of  spurious  physical conflict?”  For
this task we currently use a built-in algortithm on the tree structure level, and a three-way
merge algorithm on the file-content of text files.
+ 
+ So merge tracking is a layer on top of  tree-merging, with a clear separation of tasks.
+ 
+ This document is concerned primarily with the kinds of merges in which Subversion’s merge
''tracking'' takes effect -- that is the automatic (''catch-up'' and ''reintegrate) ''merges.
  
  === Identifying Logical Changes vs. Commits ===
  To  discuss the nuances of what exactly is tracked in Merge Tracking, we  need to think
about the difference between a raw change in the  repository (a ''commit'') and a concept
that we can call a ''logical change''.  This distinction is ''not'' implemented in Subversion
1.6.
@@ -29, +36 @@

  The whole subject of merge tracking is about whether to port the a given ''logical change''
onto the target branch, or whether that ''logical change''  has already been put there.  The
question is not about the physical  representation of that change; it doesn’t matter whether
the change was  achieved on the target branch by exactly the same physical edits as it  was
in the source branch.  The merge algorithm cannot possibly know  whether the physical change
that was committed (at the time when the  merge info says the merge happened) accurately represents
the ''logical change''  that is claimed, but if it doesn’t (or indeed if it is totally 
unrelated), then something has gone wrong at a higher level.  As far as ''merge tracking''
is concerned, that change was merged.
  
  == Merging Scenarios for Subversion 1.6 ==
- ||||<style="text-align: center;">'''Key''' ||
+ ||||<style="text-align:center;">'''Key''' ||
  ||A, B, C, … ||branches ||
  ||A:3 ||the change in branch A that was committed as revision 3 ||
  ||A ⇒ B ||a high-level relationship assumed between branches A and B, in the indicated
direction ||

Mime
View raw message