[Monotone-devel] Re: Monotone and changesets

[graydon hoare]

Nathaniel Smith wrote:

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

I think that's a bit too dismissive. the changeset work is the result of 
a very fundamental re-evaluation of monotone architecture I did this 
spring, in discussion with nathan, jerome, and daniel. it didn't used to 
track history very accurately, or give out unique names to historical 
events. now it does. that's a significant change; if it appears to have 
perturbed little on the surface, all that means is our upgrade plan was 
nice and smooth :)

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

well, we go to some pains to make sure most of the history *is* 
replicated to every peer, but you're right we don't have a "cherrypick" 
command just yet.

I'd like to clarify one thing though: the changeset work was explicitly 
intended to let us take steps in the direction of "being more 
arch-like". it's a bit like the SSA branch on gcc: interesting not so 
much for what it does in the present, as for what it enables in the 
future. now that historical events are untangled, named, and represented 
explicitly, we are much closer to being able to make a sensible 
"cherrypick" command (as well as many other UI improvements), and have 
every intention of doing so.

my intention for this sort of operation includes the case where the full 
history is not present, and we have to resort to inexact patching. 
naturally there will be a greater chance of file mismatching since 
monotone doesn't keep explicit file GUIDs the way arch does. but I think 
that's only a small (and easily resolved "by hand") part of making an 
inexact patch work, and arch's identity concept is a bit optimistic 
anyways.

imo there are cases where *any* idea of file identity will break: two 
people without a historical agreement on the assignment of IDs, or a 
file which gets factored into two sub-files, etc. so we're both going to 
have a little corner of the UI where it asks a user "um, which file do I 
land this hunk on?", I just don't think that's a big problem in an 
inexact patching command. inexact patching can also fail to apply 
altogether.. it's all part of that "inexact" word in its name :)

> > 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 sounds more complex than necessary, because some of arch's merge 
commands (perhaps not star-merge with the --three-way option?) treat 
edges as boolean sets of "applied or not" patches.

monotone's merge model is always the 3-way, so if you happen to have 
copied a lot of changesets back and forth in the interim, that just 
makes the merge edges "more similar" in the areas affected by the copied 
changes. the 3-way algorithm doesn't need to know patch numbers, it's 
always comparing edges on the fly anyways.

we'll see if arch's additional complexity makes it worthwhile; I'm 
guessing that simply copying changesets, with a flag to fuzz down to the 
patch/hunk model, will be a sufficient command. but I've been wrong 
about claims regarging arch overengineering in the past. only time and 
experience will tell.

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

yeah. I did actually build an early prototype which talked to gpgme, but 
it was very complex code compared to what I wanted.

anyways, OpenPGP keys are different from OpenPGP certs. OpenPGP certs 
don't express name/value pairs at all, just this "I trust key X from 1 
to N" setting. so we can't really use them "directly" anyways.

it's quite possible that we could teach it to import *keys* from OpenPGP 
(and SSH, and openSSL/.pem), since the RSA key primitives are just a 
couple of large integers in some arcane byte-string encoding. that is, 
assuming you're using an RSA key. in theory we could extend to work with 
DSA too, but it's a slower algorithm and the RSA patent is dead so.. 
dubious value.

in general I find the key management task works best -- contrary to the 
views of PKI vendors -- when you use a wide variety of non-automatic 
manual distribution techniques. it's easier to get working that way, and 
harder to subvert the whole security aparatus automatically due to some 
silly bug in the distribution system.

-graydon