[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Re: Future of monotone
From: |
Pavel Cahyna |
Subject: |
[Monotone-devel] Re: Re: Future of monotone |
Date: |
Mon, 28 Jan 2008 22:20:42 +0100 |
User-agent: |
mutt-ng/devel-r529 (NetBSD) |
On Mon, Jan 28, 2008 at 08:51:18PM +0100, Markus Schiltknecht wrote:
> 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.
I thought that monotone philosophy is different and branch certs are
independent of commits and mean review/approval - "mtn approve".
Pavel
- Re: [Monotone-devel] Re: Future of monotone, (continued)
- 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 <=
- 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
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Nathaniel Smith, 2008/01/29