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

[Joel Rosdahl]

graydon hoare <address@hidden> writes:

>   - doing a merge into the working copy, looking around for a bit,
>     touching it up, committing
>
> [...]
> 
> 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 what my intuition says too. And for representing conflicts in a
file x, I would be perfectly happy to do it "Subversion-style" (mark x
as conflicted in some book keeping file, put conflict markers in x and
create x.{ancestor,mine,other} files; let the user fix the conflict
and run a "resolved" subcommand that removes the conflicted state for
x). I have no good suggestion of how to represent tree layout
conflicts, though.

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

Sounds good to me.

        Joel

-- 
Joel Rosdahl <address@hidden>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97