[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: b
From: |
Christof Petig |
Subject: |
Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches) |
Date: |
Mon, 21 Jun 2004 18:16:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux ppc; de-AT; rv:1.6) Gecko/20040414 Debian/1.6-5 |
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
- Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches),
Christof Petig <=