Re: [Monotone-devel] Re: Future of monotone

[Markus Schiltknecht]

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