[Monotone-devel] Re: Monotone and changesets

[Anand Kumria]

On Sat, 20 Nov 2004 18:22:57 -0800, Nathaniel Smith wrote:

> On Sat, Nov 20, 2004 at 03:59:28PM -0500, Colin Walters wrote:
>> I have to leave soon, so I went ahead and posted.  I'm on the Monotone
>> mailing list now though, so if you want to follow up there we can have a
>> discussion there.
> 
> Sure, here goes :-)
> 
>>From http://web.verbum.org/blog/2004/Nov/20#fsrc-responses
> (see also http://web.verbum.org/blog/2004/Nov/18#orthogonal-changesets ,
> http://web.verbum.org/blog/2004/Nov/10#stofsrc):
>> I also got an email from a Monotone hacker. He said that Monotone
>> changesets are not what I had hoped. They are just a better internal
>> representation for Monotone's current architecture. So indeed, Monotone
>> still does not support cherrypicking. The claim here is that a 3-way
>> merge using complete history is better. I agree that when possible a
>> 3-way merge is usually better; the flaw though is that it assumes that
>> the complete history is available everywhere, and that
> 
> We do normally assume this in Monotone, yes; the basic communication
> paradigm is "make everything I know the union of everything I used to know
> and everything she knows" (with some algorithms similar in spirit to rsync
> to make this efficient).  This has some nice reliability benefits;
> recently a bug made Graydon's server crash whenever we try to commit
> changes to it, and he's at a conference and can't fix it.  So we've just
> been using a different server, no muss, no fuss; when he gets back and
> upgrades his server, he'll just pull the changes in that other server, and
> we'll carry on.
> 
>> one always wants to do a complete merge. So I find this argument very
>> unsatisfying; after all, right now we essentially do cherrypicking all
>> of the time when outside contributors send a diff -u to a mailing list.
>> You can of course tell contributors what to fix, and they can create a
>> new branch, and then you can merge that whole thing, but simply
>> cherrypicking some of their changes and fixing up the changes yourself
>> (while still preserving merge history) seems a lot more efficient and
>> elegant.
> 
> This part confuses me.  It sounds like by "cherrypicking" you mean
> "breaking up a diff into several small changes"?  

No, imagine this sceanario.  I fork monotone and my first change is to
s/monotone/dualtone/.  My next fix is some critical bug that exists in
both monotone/dualtone.  So the monotone developers want my second commit
_without_ my first one (otherwise they'd turn into dualtone).

> There's some extra overhead here maybe in requesting contributors to not
> pile their changes on top of each other; but everyone already requires the
> discipline to "make only one change at a time"; if I commit two different
> changes at once in Arch, IIUC it's impossible to cherrypick just half of
> that commit.  

Of course - you can't break a changeset in any upcoming VCS. But you do
want to be able to support the case of: I'll take changeset B (critical
bug fix) but not changeset A (rename monotone to dualtone).

> Furthermore, the extra information is quite valuable -- if
> it takes several patches to make one logical change, IIUC in Arch the
> maintainer has to figure out "okay, it's patch-7, patch-10, and patch-11
> that I need to integrate", and bad things happen if they make a mistake. 

Bad things happen if you make a mistake with any VCS.  I would imagine
that the monotone developer don't just integrate every change without
reviewing it.  They provide feedback on what is good and what can be
improved.

With Arch, it is common to say: 'patch-7, 10 and 11 are good; I'll take
those now.' and to 'cherrypick' just those changes.

Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -       LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -    Get bitten!