[Monotone-devel] Re: Monotone and changesets

[Colin Walters]

On Mon, 2004-11-22 at 15:50 -0500, graydon hoare wrote:

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

Ok, understood.

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

Cool.  I'll be watching what happens in this area then.

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

Or where you don't want to attempt a 3-way merge.

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

Hm.  My problem with not having GUIDs (logical file identity) isn't so
much that a patch could fail to apply, as that it could appear to apply
successfully, but to the wrong file.

> imo there are cases where *any* idea of file identity will break: two 
> people without a historical agreement on the assignment of IDs, 

Sure.  But this should be an extremely rare case, and both parties
involved will likely quickly understand the benefit of common file
identities.

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

The answer to that just depends on the situation.  Arch can easily
support the case of "neither", or "just one".  As I said on the Darcs
list though in response to Florian, if you find yourself thinking that
changesets should be applied to both, that is probably indicative of a
design problem in your project.  You'd likely want to factor out the
particular region into e.g. an internal libtool library, or a shared
Docbook entity, etc.

So I think it would be useful for Monotone to support explicit file
identity as well.

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

edges == changesets?  

The --three-way option to star-merge just tells arch to use diff3 for
conflicts, it doesn't affect the higher-level merge operator (AIUI).

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

Not sure I understand; how does this changeset copying work?  Wouldn't
that be cherrypicking?

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

Yes; although I am arguing with the Emacs/XEmacs example that you really
want that complexity (i.e. flexibility).

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

Ok.

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

Not sure I understand - wouldn't you just e.g. sign the manifest with
the OpenPGP key?

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

eek :)

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

Hmmm.  I don't like that argument very much.  If our OpenPGP
distribution system is flawed, we have very serious problems.  Having
Monotone still work in that scenario isn't all that valuable.

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