Re: [Monotone-devel] Re: Monotone and changesets

[Colin Walters]

On Sat, 2004-11-20 at 18:22 -0800, Nathaniel Smith wrote:

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

In Arch, you can easily mirror archives, and people do all of the time.
But it's not required for operation.  On the Internet, assuming that
nothing ever gets lost is probably a safe bet :)  But in a more closed
environment, one can probably imagine scenarios where history could be
lost.  In that case, Arch degrades fairly well.

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

No; I mean this:

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

That's not always the case.  It could be that the contributor just
created one branch and started working on a feature.  The feature
required some changes in the internal libraries and the application
proper.  They create a number of changesets, which happen to generally
only either affect the internal library or the application.  In Arch,
the maintainer could just cherrypick the internal library changesets,
fix them up a bit, and then tell the contributor "the application bits
need more work".  Then it's up to the contributor to create a new branch
and cherrypick just the application bits into their new branch.

In Monotone, it seems like the maintainer has to manually pick apart the
3-way merge, or punt the entire thing back to the contributor to do
likewise.

Now, it would have been better if the contributor had created separate
branches in the first place, but it's not always obvious that's the
right approach at first.

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

Right.  It's just not always obvious when you start work what is
independent and what isn't.

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

True.

> 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",

There's nothing stopping one from adding the notion of dependencies to
Arch changesets as extra metadata.

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

The other situation where you really want cherrypicking I think is a
situation like Emacs/XEmacs, where trying to do a 3-way merge since the
fork would be completely unwieldy; cherrypicking individual changesets
would be far easier.

> 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."

There does exist e.g. libgpgme.

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

Agreed, but that's not a reason to have separate keys.

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

I don't think so.  I could be submitting 5 "good" patches and then my
6th would be subtly trojaned.  The web of trust helps you here by tying
the key to a real-world identity, and thus ensures stronger
accountability.

>   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
> ...".

Yes; but obviously that's suboptimal.  It doesn't provide for automatic
revocation of the monotone key when I revoke my GPG key, nor does it
easily lend itself to programmatic analysis of my monotone committers,
for example.

signature.asc
Description: This is a digitally signed message part