[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Monotone and changesets
From: |
graydon hoare |
Subject: |
[Monotone-devel] Re: Monotone and changesets |
Date: |
Wed, 24 Nov 2004 02:44:59 -0500 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040913) |
Colin Walters wrote:
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.
it seems unlikely to me, but who knows. we'll have to wait and see.
Sure. But this should be an extremely rare case, and both parties
involved will likely quickly understand the benefit of common file
identities.
well, now we're just comparing subjective opinions on the unlikeliness
of various failures. I think it's probably an issue which will be
tolerable if either of us are right or wrong.
So I think it would be useful for Monotone to support explicit file
identity as well.
ok .. erm, I don't. but if you want to submit a patch, or perhaps talk
me into it further, I suppose I can't stop you. I can think of a few
ways to do it, but you know, it's extra code and extra concepts to add.
monotone is less than half of tla's size at the moment. that's not an
accident: I'm a bit more selective about adding new concepts.
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?
no, edge == "the sequence of all the changesets between an ancestral
point and a merge candidate". suppose you have two lines of development:
a->b1->b2->b3 and a->c1->c2->c3
if I understand correctly, arch's merge algorithm considers the presence
or absence of each changeset, a->b1, b1->b2, b2->b3, in the edge a->c3,
when deciding which changes to apply to c3. monotone compares the
composite changeset a->b3 to the composite changeset a->c3; so if for
example c1->c2 is a copy of b1->b2, then the a->c3 composite changeset
will just happen to have more in common with the a->b3 composite
changeset, making the 3-way merge easier.
Not sure I understand; how does this changeset copying work? Wouldn't
that be cherrypicking?
yeah. I expect "cherrypick" means, in monotone's context, "copy
changeset from one place to another and try to apply it". I don't think
we have much need to keep extra metadata about that copy. maybe we will,
I'm not certain.
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?
well, we use certs to express arbitrary name=value metadata, such as
"branch=foo" or "author=bob". we could write this string out and then
make an OpenPGP signature of it, but then OpenPGP is really not serving
much more than an RSA signing mechanism, and it's a bit complex for such
a simple task. (note: tla doesn't use gpgme either; it just forks and
execs a shell command it reads from a text file and captures the result:
lots of failure cases, terrible performance)
I'm not arguing this in terms of ideals, I'm arguing it mostly in terms
of implementation pragmatics. our crypto glue costs only a couple
hundred lines of code, and can chew through thousands of certs per
second. the keys, certs, and signatures are just simple strings kept in
the same general SQL store. gpgme would have been thousands of lines of
code, with dozens of potential leaks and failure modes related to
misconfiguration, process management, environmental interaction, etc.
I'd have had far less confidence that it was working right, and I'd have
very little recourse if it performed poorly.
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 :)
no, I mean that for real. it'd probably win most of the benefits you
want, and it's just a parsing problem. very likely less hassle than
trying to migrate to gpgme, and more likely to be innocuous in terms of
performance. keep in mind, we're doing bulk operations which can require
thousands of verifications. it's important to be fast.
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.
oh, I think the OpenPGP distribution system is full of flaws, chief
among them transitive trust system. the meet-and-greet aspect of it is
also nonsense imo, but mostly my objection is just that it's
overengineered, hard to understand, hard to use, hard to integrate into
programs, etc. if integrating it was only a few extra lines of code, I'd
be happy to put my security objections aside.
I do understand there's value to be had from interoperability, just not
*unlimited* value. SSH and SSL don't speak OpenPGP either, yet they seem
to work.
-graydon