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] Trivial Update of "SupportedMergeScenarios" by JulianFoad
Date Thu, 19 Jan 2012 14:25:18 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=6&rev2=7

Comment:
Fix formatting of last change

  
  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.
  
+ 
  ### NEW text to be edited in:
  
  In order to make sense of this, I consider the definition of a tracked change to be:
  
     * The unit of change tracked is a logical change to the versioned  tree, which was originally
committed to one branch, which has a meaning  or purpose that remains the same no matter which
branch it ends up being  merged onto.
  
-  The meaning or purpose of a logical change is typically described in the  log message of
the original commit.  A realistic example is "Delete  function foo() and change all callers
to use the similar function bar()  instead".
+ The meaning or purpose of a logical change is typically described in the  log message of
the original commit.  A realistic example is "Delete  function foo() and change all callers
to use the similar function bar()  instead".
  
-  Merge tracking should treat every original commit as that kind of  "logical change".  This
definition doesn't presuppose that every commit  is *actually* relevant to every other branch
in your project.  If and  when you want to merge this change to a branch that doesn't have
a  function foo() and code that calls it, then clearly you have logical  conflict between
the states of the two branches.  This change and almost  certainly a series of other changes
will either be inapplicable or will  need some minor or major editing to resolve the logical
conflict to  make them applicable.  Resolving such conflicts, including omitting  changes
by hand that the system says logically should be merged, is a  normal and expected part of
merging.
+ Merge tracking should treat every original commit as that kind of  "logical change".  This
definition doesn't presuppose that every commit  is *actually* relevant to every other branch
in your project.  If and  when you want to merge this change to a branch that doesn't have
a  function foo() and code that calls it, then clearly you have logical  conflict between
the states of the two branches.  This change and almost  certainly a series of other changes
will either be inapplicable or will  need some minor or major editing to resolve the logical
conflict to  make them applicable.  Resolving such conflicts, including omitting  changes
by hand that the system says logically should be merged, is a  normal and expected part of
merging.
  
-  The physical manifestation of a given logical change will in general  differ on different
branches.  In simple cases the physical  manifestation will be similar: for example, the default
"svn diff"  output may be the same except for the line numbers.  In a slightly less  trivial
example perhaps the context lines will also be different.  And  getting bit more involved,
perhaps the removed "-" lines will be  slightly different but the added "+" lines will be
just the same.  Or  perhaps the diff will be just the same except in a renamed file.  (Side
 note: Although what we mean by the physical manifestation is kind of  obvious, in  fact it
is subtly hard to pin down, because it depends entirely how you  represent the physical change.
 If we look at "svn diff" output, for  example, differences between the source branch and
the target branch in  other lines of the file are  hidden even though they might be important
for the correctness of the  patched lines.)
+ The physical manifestation of a given logical change will in general  differ on different
branches.  In simple cases the physical  manifestation will be similar: for example, the default
"svn diff"  output may be the same except for the line numbers.  In a slightly less  trivial
example perhaps the context lines will also be different.  And  getting bit more involved,
perhaps the removed "-" lines will be  slightly different but the added "+" lines will be
just the same.  Or  perhaps the diff will be just the same except in a renamed file.  (Side
 note: Although what we mean by the physical manifestation is kind of  obvious, in  fact it
is subtly hard to pin down, because it depends entirely how you  represent the physical change.
 If we look at "svn diff" output, for  example, differences between the source branch and
the target branch in  other lines of the file are  hidden even though they might be important
for the correctness of the  patched lines.)
  
-  It's important to consider complex examples of change.  A change like  adding "This is
a new line" to the end of file "foo" is often too simple  to demonstrate merge tracking requirements.
 With such an example, the  tree-merge layer is quite likely to DTRT no matter what the merge
 tracking layer says.  But important changes aren't always like that;  important changes often
can't be automatically merged at the tree-merge (or text-merge) level.
+ It's important to consider complex examples of change.  A change like  adding "This is a
new line" to the end of file "foo" is often too simple  to demonstrate merge tracking requirements.
 With such an example, the  tree-merge layer is quite likely to DTRT no matter what the merge
 tracking layer says.  But important changes aren't always like that;  important changes often
can't be automatically merged at the tree-merge (or text-merge) level.
  
-  IMPLEMENTATION
+ IMPLEMENTATION
  
-  Of course the merge tracking implementation is written in terms of  tracking physical changes
(commits), not logical changes.  In simple  cases that gives exactly the same result, but
I view the ''purpose'' as  being to track logical changes, and so when we consider cases where
the  two approaches require different outcomes then I look at the latter.
+ Of course the merge tracking implementation is written in terms of  tracking physical changes
(commits), not logical changes.  In simple  cases that gives exactly the same result, but
I view the ''purpose'' as  being to track logical changes, and so when we consider cases where
the  two approaches require different outcomes then I look at the latter.
  
  == Merging Scenarios for Subversion 1.6 ==
  ||||<style="text-align:center;">'''Key''' ||

Mime
View raw message