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 "MergeDev/MergeTheoryTopics" by JulianFoad
Date Fri, 26 Apr 2013 11:36:05 GMT
Dear Wiki user,

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

The "MergeDev/MergeTheoryTopics" page has been changed by JulianFoad:

New page:
''Design notes, plans and ideas.''

''This is not part of the official documentation of Subversion. It is aimed at the developers
of Subversion, and may not reflect reality or the project community's plans. For official
documentation, see''''.''

The aim of this page is to hold initial design notes and ideas on all of the topics
relevant to the theory of merge tracking, in the context of enhancing merge support
in Subversion after 1.8.  It does not aim to comprehensively cover each topic.

== Per Node or Per Tree Semantics ==

A 'branch' consists of a set of nodes at any given time, but the set of
nodes is not fixed, it varies over time.  Nodes can be added and deleted.
(Can a node be moved into or out of a branch?  What does it mean?)

Therefore, asking 'what changes have been made on branch A?' involves more
than querying merge history for each node that is *currently* on branch A.

== Relationships Between Branches ==

  "As soon as the relationship between branches ceases to be a tree, it
  becomes impossible for users to understand what's going on. [...] I'm in
  favor of the version control system not allowing you to do goofy things,
  and keep track of the coherent relationships between branches"
    -- Bram Cohen.

  [A VCS should] have the shadowing concept be built in from the ground up.
  And allow the safe forms of reparenting. And make sure that the branch
  relationships and their changes are kept in the history along with
  everything else.
    -- "Version Control Recommended Practices" (point 9), Bram Cohen

See Perforce's "Merge Down, Copy Up".

See Perforce's "Streams".  Stream types: mainline, development, release.
Stream policies: "merge down, copy up".

Does Mercurial have something towards this?

== Fast-Forward ==

Fast-forward merge should:

  * Ensure minimal changes are sent to/from a WC.

  * Leave merge history that clearly shows no changes were committed
    but the target was simply rebased.

== Unrelated Changes ==

Theory of committing an unrelated change along with a merge.

I think, to make sense of arbitrary merging across multiple branches,
unrelated changes should not be supported.  (They should be seen as part of
conflict resolution.)  Then, changes can be merged physically from any
convenient branch in the graph.  If an unrelated change is required to be
"tracked" (treated as a logical change that must be merged to the target
branch), then all required changes in a merge have to come physically from
the specified source branch.

Doug Robinson said, for criss-cross, we must assume user may have committed
an unrelated change each time, and therefore the two branches cannot be
considered equivalent until either a complete merge is done one way or the
user explicitly tells the VCS that the branches are equivalent.

== Cherry-Pick ==

Theory of tracking cherry-pick merges as well as full merges.

== Subtrees ==

>From [NewMerge]: "If you want to work on a subtree, you can make a new
branch [...] that contains the subtree.  We can track its relationship and
merge it back to the complete tree."

== References ==

 * Subversion Wiki, Julian Foad,

 * "NewMerge", Assembla,

 * "version control tidbits", Bram Cohen,

 * "Git Can't Be Made Consistent", Bram Cohen,

 * "Rebasing", Bram Cohen,

 * "Version Control Recommended Practices" (point 9), Bram Cohen,

 * "Stream Types", Perforce,

 * "CM Research Papers and Experience Reports", Brad Appleton,

 * "Using git fast-forward merging to keep branches in sync",

 * "MarkMerge",

''This page was written initially by JulianFoad and may be edited by others.''

View raw message