subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de>
Subject Two-phase merge
Date Tue, 24 Apr 2012 20:51:55 GMT
Hi all,

This one is basically the technical post promised in my
"Merge Policies" post. The proposal I make here is not
an alternative to e.g. "Symmetric Merge" but rather a
refined merge strategy that would also benefit the current
merge.

Today, the merge algorithm will do the following for a
merge from A -> B:

* read / evaluate the merge info and change history
   to find the list of revisions to merge
* fragment the list of revisions where they are non-
   contiguous; fragment = a revision range to merge
* iteratively merge all fragments from A to B,
   optionally resolve conflicts after each fragment

In end, we will always merge individual file or property
changes but we plan the merge on tree-level. For many
file nodes, this will unnecessary intermediate states
where the merge got fragmented due to a change to
some *other* file. This increases the probability of
merge conflicts and their likelihood to show up again
after each conflict resolution. Moreover, it masks cases
where Symmetric Merge might select an optimized
merge plan (see wiki for various examples).

I propose to use the following two-phase merge workflow:

(1) Planning phase
- read / evaluate the merge info and change history
   to find the list of revisions to merge
- break that down for each node changed on the source side
- optionally handle renaming etc.
- mark tree conflicts (not sure when to signal them to the
   user and when to resolve them; high-level fragmentation
   might become necessary)

(2) Execution phase
- merge changes on a per-node basis, i.e. all changes of
   that node get merged before the next node
- fragmentation may still be necessary for *that file*
- given the "merge plan" for a node, alternative merge
   strategies may be chosen

That's all I currently have on merge and is not very
very long-term ;)

-- Stefan^2.

Mime
View raw message