Re: [Monotone-devel] Commit a child of 2 parents

[Jon Bright]

Daniel Carosone wrote:
> On Sun, Jan 15, 2006 at 09:21:27PM -0500, Yury Polyanskiy wrote:
> > The other way is to hack SP and make it call regular monotone commands.
> > In this latter case, of course it'd be nice if the tool worked with
> > standard monotone releases, not some specially patched ones. So I'm
> > just looking for a way to do this.
>
> Ahah, now here's a very straightforward and concrete requirement that
> will help guide the interface design for the feature we already knew
> we'd probably want for something.  Programs like tailor are likely to
> want very similar features.
>
> For now, i'd suggest you use the hooks-style approach to supply the
> merge with the correct file content from the equivalent BK rev.

A similar requirement arises when implementing the merge interface for 
an Eclipse plugin.  The workflow would be something like:

1. "Synchronize" with DB
2. Eclipse shows which files have incoming updates, which have outgoing 
and which have both.
2a. See below
3. Click "Update" (NB: You can do this for a subset of files rather than 
the whole working copy - but I guess that's another problem)
4. Eclipse merges those files without conflicts, pops up a message about 
other files.
5. For each other file, in any order the user feels like, the user gets 
a nice merging interface which he/she uses to do the merge, marking the 
file as merged afterwards.

2a. You can do step 5 here for any files you feel like, too.

At any stage, the user can stop and go do something else - including 
playing with the working copy.  The user can choose to merge everything 
manually if so desired.  The user can merge just one file, then go and 
play with the working copy.

I've had some thoughts about how to square all this with monotone's way 
of working, but this mail is really just food for thought if someone's 
planning on changes to monotone's merging interface.

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com