[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Monotone and changesets
From: |
Colin Walters |
Subject: |
[Monotone-devel] Re: Monotone and changesets |
Date: |
Tue, 23 Nov 2004 23:22:31 -0500 |
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