[Monotone-devel] Re: Monotone and changesets

[Nathaniel Smith]

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"?  But I thought Arch
didn't do this either.

If you mean that they've made a bunch of independent changes and
concatenated them in their history, then yeah, this is a bit
problematic.  I don't know that I believe in this user, though; this
would have to be someone who 1) is bothering to use the VCS tool,
instead of just sending a diff -u, but 2) doesn't bother to use the
VCS tool correctly.  What I mean is, in my head (we don't quite have
enough experience yet to say, but this seems to be what's we're
falling into for Monotone development), the preferred way to make a
change is to make that change against the mainline, possibly on a
branch, and if you want to make a separate independent change, you
also make that against the mainline, possibly on a branch:

   Mainline: A -> B -> C -> D
              \         \
   Change 1:   A'        \
                          \
   Change 2:               A''

Then you ask for it to be integrated, and either the maintainer does
so, or he requests more changes (or may make some more changes
himself):

   Mainline: A -> B -> C -> D
              \         \
   Change 1:   A' -> B'  \
                          \
   Change 2:               A''

But now you realize that some reorganization in D broke your code, so
you need to make a few more changes; so you integrate D and do your
fixes (while development continues on mainline):

   Mainline: A -> B -> C -> D -> E
              \         \    \
   Change 1:   A' -> B' -\--> C' -> D'
                          \
   Change 2:               A''

And now the maintainer integrates your fix:

   Mainline: A -> B -> C -> D -> E -> F
              \         \    \       /
   Change 1:   A' -> B' -\- > C' -> D'
                          \
   Change 2:               A''

And then you point out that your other fix got forgotten, and the
maintainer says "doh, right, looks good to me", and merges it:

   Mainline: A -> B -> C -> D -> E -> F -> G
              \         \    \       /    /
   Change 1:   A' -> B' -\- > C' -> D'   /
                          \             /
   Change 2:               A'' --------/

At no point was there any need to do anything but a real 3-way merge,
and the 3-way merge was always well-defined and minimal.  Also, while
it would be nice to use branches, maybe (and making a commit a branch
is completely trivial in monotone), once we beef up the trust logic a
bit, all of the above will work pretty much identically whether the
contributor used branches or not.  In fact it works that way now, it
just takes a bit more human attention than we'd like.

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.  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.  While with Monotone's
recommended model, this is taken care of for you.  (Of course, in Arch
if you're using branches properly you're doing the same thing as
in Monotone's recommended model, right?)

> This is mostly a fixable technical detail, but I'm also a bit unhappy
> with Monotone's usage of RSA certificates rather than OpenPGP keys.
> Some of us have spent quite a bit of time building up links in the web
> of trust, and don't particularly feel like generating trust around a
> new key, protecting it, etc.

There's some reply to this in the FAQ:
"GPG as a subprocess is slow, tricky and fragile; crypto++ in-process
is fast, simple and reliable.  OpenPGP packet format is quite baroque,
we need much less than it can do."

I'd also add:
  1) As Graydon points out, the web of trust is really the wrong
formalism anyway.  "I trust patches signed by key ..." is almost
completely orthogonal to "I trust that I know the full legal name of
the owner of key ...".  At the least, you need some extra layer of
trust; there's no way that I trust everyone who has a well-connected
GPG key to write good code!  So you have to specify that anyway.  And
for that matter, you don't need assurance of somebody's legal identity
in order to trust their patches -- in practice, I trust new patches
signed by your key because the last 5 patches signed by your key were
also good.  So the web of trust is mostly irrelevant.
  2) If you do still want to use the web of trust, though, it's
trivial; just send out a GPG-signed email saying "my monotone key is
...".

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff