[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: Future of monotone
From: |
Markus Schiltknecht |
Subject: |
Re: [Monotone-devel] Re: Future of monotone |
Date: |
Mon, 28 Jan 2008 20:51:18 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.9 (X11/20080110) |
Hi,
Thomas Moschny wrote:
Maybe. I wrote it that way for brevity. As some certs may have more logical
value fields then others, but should all be put in the same SQL table, you
would have to stuff some valued into the same field (from the tables pov),
no?
Yes, all the information which can be different from cert to cert. That
is: 'tag', 'branch', the test result information.
But IMO not: 'signer', 'author', 'date', and 'comment'
There's something missing. Where would you put the 'comment', 'branch', 'tag'
and 'value' data from the table above?
Oops, yeah, I forgot about the comment field. Let's try it again:
CREATE TABLE new_revision_certs
(
hash not null unique, -- consistency checking hash
rev_id not null, -- joins with revisions.id
name not null, -- name of the cert
date not null, -- timestamp of the cert
comment, -- optional comment on the cert
value not null, -- the tag name or test result value
author not null,
signer not null,
signature not null
);
With that table, we would have a reduction to the following certs:
- 'commit(-message)' certificate (where changelog -> comment and
branchname -> value)
- 'tag' certificate (tagname -> value)
- 'test-result' certificate. (test result -> value)
Every cert, even "private" ones, would then be required to also have a
date and an author. Optionally also a comment.
In a way, this certainly complicates matters. And I'm not quite
convinced, that the above scheme is better than what we have now.
However, I certainly agree that we should maintain the connection
between the current 'author', 'branch', 'changelog' and 'date' certs,
which are mostly created in one atomic step.
But maybe, there are other ways to keep those certs connected?
Regards
Markus
- [Monotone-devel] Re: Future of monotone, (continued)
- [Monotone-devel] Re: Future of monotone, Bruce Stephens, 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: Future of monotone, Bruce Stephens, 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
- Re: [Monotone-devel] Re: Future of monotone,
Markus Schiltknecht <=
- 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, 2008/01/28
- 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