On Mon, Apr 16, 2012 at 12:25 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> I have written out how I think a large part of the symmetric merge
> algorithm should go, in more detail. Review and other feedback would
> be welcome.
>
> We need to write out the algorithm in this level of detail and a
> little more detail, and then write several new functions for
> implementing parts of it. I had until recently been thinking that I
> would be able to re-work most of the existing functions to accomodate
> what we need, and I have made some improvements along the way, but
> that is proving too difficult. (I started making some notes in
> <http://wiki.apache.org/subversion/MergeCodeImprovements> about things
> that I think we should be looking to change in the existing merge
> code.)
>
> At this point I haven't included processing of subtree mergeinfo in
> the algorithm description, though I have that in mind too.
Hi Julian,
So what is your plan for dealing with subtree mergeinfo then?
Implement the following then try to deal with it? Or get agreement on
what you have here then try to add that on? I worry about proceeding
to far without considering how subtree mergeinfo will be handled,
since most of the difficulties with and subsequent improvements to
merge tracking since 1.5 related to subtree mergeinfo.
And what about other merge "edge" cases, e.g. shallow merges, shallow
merge targets, merge targets with missing subtrees (due to switches or
authz restrictions). Just some things to keep in mind (FWIW the merge
test coverage is pretty thorough in these areas so breakage will be
obvious).
Paul
Received on 2012-04-17 17:39:31 CEST