[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branc
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches) |
Date: |
Thu, 13 May 2004 00:17:43 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040208) |
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
- [Monotone-devel] branches, Derek Scherger, 2004/05/02
- [Monotone-devel] Re: branches, graydon hoare, 2004/05/03
- [Monotone-devel] Re: branches, Derek Scherger, 2004/05/03
- [Monotone-devel] Re: branches, graydon hoare, 2004/05/03
- Re: [Monotone-devel] Re: branches, Christof Petig, 2004/05/04
- [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Christof Petig, 2004/05/11
- Re: [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Patrick Mauritz, 2004/05/11
- [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches),
graydon hoare <=
- Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches), Joel Rosdahl, 2004/05/13