Markus Schiltknecht schrieb:
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.
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. Is it really so important that the author of a change deserves a separate field instead of just getting honored full-text in the commit message itself? Or if we have both, value and comment, that we put the author in the comment field of a commit cert?
Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
