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

[Christof Petig]

Sorry for me breaking the referral-chain, this is a reply to a 
cut'n'paste text from the archives.

graydon hoare schrieb:
> 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.

While I'd love to commit the nonconflicting parts, the resulting 
manifest will not compile most of the time when there are conflicts in 
some files and clean merges in others. Partially resolved manifests 
should get a cert "don't use me except when merging".

If I understand correctly this (best merge possible) does not yet allow 
parallel conflict resolving by several people (in different parts of the 
tree). When redesigning/enhancing merge I wanted to make this possible 
since I see this one as one of the biggest shortcomings of CVS. I simply 
wanted to say "Hi Joe, I merged A and B. The resulting tree is C. Can 
you take a look at the conflicts in the D directory while I resolve them 
in the E directory?"

Whether this is easily possible is another problem (especially if you 
replace Joe by _several_ different people).

> I don't really want to introduce new
> concepts like "the status of a given file relative to the task of
> merging".

I did not want to introduce "status of a given file", only "status of a 
manifest" relative to the task of merging [42 files merged, 24 to go]. 
And if you merge file by file you need the ID of the two/three ancestors 
stored somewhere. My idea is based on committing such an intermediate 
state as a new manifest.

Do you see any flaw in this design?

> 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.

I see that if you merge into a working copy you need to identify the two 
ancestors of this manifest when committing. So this file is needed to 
store the information.

Perhaps better proposal: do not include any conflicting files in the new 
manifest but include a MT/pending-merges and the hash of it's contents. 
It would contain the target file name and the two/three ancestor IDs 
needed for a merge.

The harder part would be to merge two manifests which incrementally 
resolve different conflicts. [Metadata conflicts need to be handled 
differently (e.g. rename conflicts etc.)]
E.g. you can allow to only change unresolved conflict markers by content 
[adding files to the manifest and removing them from MT/pending-merges]. 
Resolving the conflict two times (or changing a normal file) might 
result in a metadata (manifest) conflict.

> 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).

Though I think this change is reasonable unrelated to the things you 
head for (and can be implemented in parallel by me).

> does it seem a sensible enough way forward, though?

perhaps. I'll wait for your answers.

   Christof