monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Moving monotone databases


From: Bruce Stephens
Subject: [Monotone-devel] Re: Moving monotone databases
Date: Sat, 20 Nov 2004 17:55:25 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux)

Nathaniel Smith <address@hidden> writes:

[...]

> To make that a little more concrete --- it is mathematically
> impossible to do exactly what you want, because 1) you can't modify
> or get rid of a cert once it's issued, it's out there in everyone's
> database, so you can't reach out and change/eliminate all the
> existing branch certs, and 2) even if you just want to make
> duplicate branch certs with the new name, you can't preserve trust
> information.  Obviously, if Alice signed the original branch cert,
> you can't issue a new one that's also signed by Alice.  The best you
> can hope for is to issue a new one signed by you.  Of course, this
> raises some problems, because you have to decide once and for all
> whether you trust Alice's stuff --- if Bob trusts you but not Alice
> (or vice-versa!), then weird things will happen when you reissue her
> certs.  Worse is if you _don't_ trust Alice... do you reissue her
> certs then or not?

I don't buy it.  Conceptually, that is---I agree that as monotone
currently does things this probably can't work.  

However, what if you added a layer of indirection: so branch certs are
immutable (so the structure doesn't change), but the relatively
unimportant strings that we humans give to branches can?  

So the unchanging identifier for branches would presumably be the SHA1
of something (doesn't matter of what: the public key of the signer and
the revision that they're attaching the branch cert to, say).  And
that's the identifier which would automatically be used in descendent
branch certs.  

Then you'd add some way to map between convenient strings like
"net.venge.monotone.foobar" and these SHA1 hashes, and you could
(somehow) allow that mapping to change over time.

I'm being rather vague about how this mapping might work because I've
no idea.  Presumably it's useful for people to agree on the mapping,
at least most of the time, so maybe some kind of cert is appropriate.
But then maybe not; I'm not sure.

It doesn't seem trivial, but I'm not convinced that there's no way to
do it.

> So, if you can get away with it, the simplest thing by far is just to
> start committing to the new branch, and get everyone else to do it
> too.  You don't lose any history, everything should still work...

Yes indeed.

> All that said, it _is_ handy sometimes to do the cert reissue thing.
> If you decide that that's what you want, then you can either write a
> little script --- which should be pretty straightforward, I think
> --- or try to convince us that it's handy and common enough that
> such a script should be folded into monotone proper :-)

Yes, for the case where you haven't distributed something, it might
well be convenient to be able to change things, if only to correct
typos.

[...]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]