Paul Burba wrote: > Julian Foad 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. [...] >> 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?
In brief, my plan is to develop a way forward through discussion with the community. Thank you for engaging and helping with this. > 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. Yup, me too. > 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). Yup. FWIW, the way I work, and from the position from which I'm entering, the most difficult step is describing what we want the behaviour to be, and then implementing it is (still hard but) the lesser task. So I'm concentrating on trying to create a descriptive model of what merging should do. You tested a number of scenarios (mainly by making the test suite run my symmetric-merge initial trial implementation and analyzing what happened) and that was very useful. I found that I needed to give more thought to the functional design and that's why I didn't reply directly to those emails. - Julian
