[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Future of monotone
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] Re: Future of monotone |
Date: |
Tue, 29 Jan 2008 04:45:14 +0000 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Mon, Jan 28, 2008 at 08:51:03PM -0700, Derek Scherger wrote:
> Thomas Keller wrote:
> >
> >Does it really make sense to have an author field for anything beside a
> >commit cert? If you tag or test something, you do not become the author
> >of anything, you just mark something somehow. When I look at the
> >proposed database table schemes so far I somehow have the impression
> >that we rather have a hard time of applying the same metadata which fit
> >perfectly for non-commit certs on commit certificates - i.e. tag,
> >branch, suspend and testresult perfectly fit into the
> >(name,value,comment?,date,signer,signature) tuple scheme, just commit
> >certs do not because they can optionally have an author which is
> >different from the signer.
>
> One reason for separating out the author from the signer is that, in the
> event of a database rebuild, all certs will be re-signed by whoever does
> the rebuild and the original author is lost. This has happened a few
> times in the monotone history and while not a huge problem does leave
> rebuild a little more lossy than it could be.
My current feeling is that separating out signer from author is a bad
idea. The cost of having them is paid all the time -- you have two
different identities to worry about every time you print a log
message, there are security concerns (people who are confused about
identity can cause a mess), etc. The cost of not having them is this
annoyance with database rebuilds, which are *very* rare, and for them
ad hoc techniques suffice. (For instance: just munge a note about the
original author into the commit message programmatically.)
-- Nathaniel
--
In mathematics, it's not enough to read the words
you have to hear the music
- Re: [Monotone-devel] Re: Future of monotone, (continued)
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- [Monotone-devel] Re: Re: Future of monotone, Pavel Cahyna, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Keller, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Derek Scherger, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone,
Nathaniel Smith <=
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/29
- [Monotone-devel] Re: Future of monotone, Bruce Stephens, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Julio M. Merino Vidal, 2008/01/29
- [Monotone-devel] Re: Future of monotone, Bruce Stephens, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Julio M. Merino Vidal, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Nathaniel Smith, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- RE: [Monotone-devel] Re: Future of monotone, Kelly F. Hickel, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29