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 "MergeTrackingIdeas" by JulianFoad
Date Wed, 11 Jan 2012 08:25:16 GMT
Dear Wiki user,

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

The "MergeTrackingIdeas" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/MergeTrackingIdeas?action=diff&rev1=1&rev2=2

Comment:
Tweaks to 'Multiple commits in same merge'

   * User-facing goals defined in terms of merging the right set of ''logical changes''.
   * Each commit is either a ''logical change'' or a ''merge'' of ''logical changes''.
  
- We introduce the concept of a ''logical change'' as the fundamental unit of change that
is tracked.  A ''logical change''  starts life as a committed change that is not part of a
merge.  When  that tree-content change is merged to another branch (adapted if  necessary
to accommodate any physical and/or semantic differences  between the branches), the resulting
commit is ''not'' a new ''logical change'' but rather is a ''merge''.  A ''merge'' is defined
as a committed change that includes a mergeinfo change that brings in one or more ''logical
changes''.  A ''logical change''  has a unique identifier (let’s say the branch and revision
in which it  was originally committed) and is always identified by that same  identifier,
no matter what branches it has been merged through or  whether it has been merged together
with other ''logical changes'' in a single ''merge''.
+ We introduce the concept of a ''logical change'' as the fundamental unit of change that
is tracked.  A ''logical change''  starts life as a committed change that is not part of a
merge.  When  that tree-content change is merged to another branch (adapted if  necessary
to accommodate any physical and/or semantic differences  between the branches), the resulting
commit is ''not'' a new ''logical change'' but rather is a ''merge''.  A ''merge'' is defined
as a committed change that includes a mergeinfo change that brings in one or more ''logical
changes''.
+ 
+ A ''logical change''  has a unique identifier (let’s say the branch and revision in which
it  was originally committed) and is always identified by that same  identifier, no matter
what branches it has been merged through or  whether it has been merged together with other
''logical changes'' in a single ''merge''.
  
  We must be able to identify the ''logical changes'' in the system.  To identify the ''logical
changes ''in existing 1.6 mergeinfo, we will classify each commit as a ''logical change''
if it is a change without any mergeinfo change, or else as a ''merge'' if it includes a mergeinfo
change.  If it’s ''merge'',  then it brings in some pre-existing logical changes and/or
merges.  By  scanning recursively into mergeinfo history, we can identify all the  original
logical changes brought in by a merge.
  
@@ -67, +69 @@

   * Quick(ish)  traversal of mergeinfo history.  This suggests a new storage model in  which
all the historic mergeinfo (of a given branch?) is in one place.
  
  === A Worked Example ===
- == Multiple Commits in One Logical Change ==
+  . [TODO]
+ 
+ == Extension: Multiple Commits in The Same Merge ==
+ We might want to allow multiple revisions to be recorded as being components of the same
''merge''. For example, sometimes a user will choose to commit the initial result of a merge
first, and then do further conflict resolution and commit again. Without this extension, the
first of these commits would be tracked as a ''merge'', and the second would wrongly be classified
as a new ''logical change''. We could design a way to be able to track these two commits as
a single logical ''merge''.
+ 
- We might want to allow multiple revisions to be recorded as being components of the same
''merge''.   This would increase the power of merge tracking in a functional sense,  but it
is “advanced” functionality and would require user awareness and  tool support to make
use of it.
+ This would increase the power of merge tracking in a functional sense,  but it is “advanced”
functionality and would require user awareness and  tool support to make use of it.
  
  Merge  A:10 to B, committing the result initially as B:13, then doing some  more conflict
resolution in B:14 and B:16.  Arrange somehow (by user  input, for example) for B:14 and B:16
also to be recorded as part of the  “same” merge: branch B revs 13, 14, 16 jointly comprise
the merge of  A:10.  In a subsequent merge from B to C, assuming A:10 is already on C,  that
would prevent B:13, B:14 and B:16 from being merged to C.
  

Mime
View raw message