[Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches)

[graydon hoare]

Christof Petig wrote:

> I would love to see a cooperative merging possible within
> monotone. Like "merge two heads, mark conflicts somewhere and commit the
> conflict markers as a new manifest. Then multiple people might be able 
> to resolve the conflicts (distributed in time and space=files) until all
> are done and the version gets official."

I think there are really two ideas at work here:

 - doing a "partial merge" and committing the results
 - doing a merge into the working copy, looking around for a bit,
   touching it up, committing

for the former, I think I prefer what oxygene suggested: make a 
conservative "best merge possible" node, with two children containing 
the "residual" non-merged parts. I don't really want to introduce new 
concepts like "the status of a given file relative to the task of merging".

however, for the latter it seems everyone's intuition is that the 
working copy is a perfectly reasonable place to drop a merge, for 
inspection, before committing it.

that's ok; at worst I think all it requires is adding a new file 
MT/merge-inputs which lists all the auxiliary manifests which are 
considered "inputs" to the current working copy. when you commit, an 
ancestor cert is added for each input. it's doable. I'd then probably 
change the merge and propagate commands to write out to the working copy 
by default, with a flag say "--nowc" or "--inmemory" to indicate the 
special (apparantly less-intuitive) form of merging with no working copy.

these changes will be a couple releases off; there are still a few 
practical matters to resolve before then (netsync has some performance 
bug, there are lots of UI bugs, disapproving needs to be rewritten).

does it seem a sensible enough way forward, though?

-graydon