Hi Boris,
Boris wrote:
* I need a kind of project branch to put several projects into the same
monotone database. I want everyone to be free to create new branches but
I don't want everyone to be so free that branches which are actually
different projects are mixed up. Putting every project in
On Sun, 27 Jan 2008 15:41:37 +0200, Thomas Keller <[EMAIL PROTECTED]>
wrote:
[...]So where lacks monotone the most? In my humble opinion its probably
Hi there,
I've been introducing monotone to some commercial software projects about
one year ago. I don't know how many use monotone to mai
Graydon Hoare wrote:
My plan here was to rip out netsync, packets, basic_io, netio, and the
old cert system. Put in the new cert system and the new sync system, and
replace the automate commands with json-speaking equivalents. Do away
with all the legacy i/o stuff, and provide one that's actu
Thomas Moschny wrote:
On Monday 28 January 2008, Graydon Hoare wrote:
I think it's a good branch as they go in this sort of thing. I just ran
out of interest.
Sorry to hear that, but that's life, it seems.
It contains a variety of interrelated new code. Anyone
else is welcome to pick it up o
"Julio M. Merino Vidal" <[EMAIL PROTECTED]> writes:
> On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote:
[...]
>> Having one person commit something that someone else authored is
>> routine (it's the way that most public git projects operate), and yes,
>> git distinguishes committer and author.
Hi,
Nathaniel Smith wrote:
If you need clean roundtripping, author fields are hardly your worst
problem.
Sure, but that's no reason for dropping differentiation between signer
and author.
You're going to need to add extra system-specific metadata
regardless, and hey, look at these nice use
Hi,
Kelly F. Hickel wrote:
Hmm, doesn't that suggest that *every* cert needs an "original signer"
in addition to the signer?
Uh.. yeah, sort of. We were referencing to that person as the author, I
think.
Regards
Markus
___
Monotone-devel maili
On Tue, Jan 29, 2008 at 12:40:56PM +0100, Markus Schiltknecht wrote:
> Yeah, and that argument gets even stronger if you take imports or
> pulling from foreign VCSes into account: you will have to pull in
> commits, tags and branches, and certainly can't recycle the "cert" from
> the source VCS
> 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
>
Hi,
Derek Scherger wrote:
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 pr
On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote:
Thomas Moschny <[EMAIL PROTECTED]> writes:
[...]
We also should have a look at what other VCSs do here - does
e.g. git discriminate between author and signer?
"Signing" is much less significant in git.
Having one person commit something t
Thomas Moschny <[EMAIL PROTECTED]> writes:
[...]
> We also should have a look at what other VCSs do here - does
> e.g. git discriminate between author and signer?
"Signing" is much less significant in git.
Having one person commit something that someone else authored is
routine (it's the way th
On Jan 29, 2008, at 5:45 AM, Nathaniel Smith wrote:
On Mon, Jan 28, 2008 at 08:51:03PM -0700, Derek Scherger wrote:
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
On Tuesday 29 January 2008 Nathaniel Smith wrote:
> My current feeling is that separating out signer from author is a bad
> idea. The cost of having them is paid all the time
> different identities to worry about every time you print a log
> message,
First, we already have this situation with th
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
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 impre
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
Hi!
Markus Schiltknecht wrote
> 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)
> - 'tes
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 b
Markus Schiltknecht wrote:
> Thomas Moschny wrote:
> > name = 'commit', value = (author, date, comment=changelog, branch)
> > name = 'tag', value = (author, date, comment, tag)
> > name = 'suspend', value = (author, date, comment, branch)
> > name = 'test-result', value = (author,
Hi,
Thomas Moschny wrote:
Hmm, it's more like this:
name = 'commit', value = (author, date, comment=changelog, branch)
name = 'tag', value = (author, date, comment, tag)
name = 'suspend', value = (author, date, comment, branch)
name = 'test-result', value = (author, date, comme
Markus Schiltknecht wrote:
> So in your world, there still are:
>
> - 'commit' (branchname => value, changelog => comment)
> - 'tag' (possibly with a comment)
> - 'test-result' (possibly with a comment)
>
> Right? Hm... so every cert would have a value, a date, a signer and
> possibly
On Monday 28 January 2008, Bruce Stephens wrote:
> Locality on disk, such that commonly the certs that you want to
> request are close together (and so more efficient to read).
>
> I guess lumping certs associated with a revision together might be
> good, but maybe not---maybe you want certs for a
Hi,
Thomas Moschny wrote:
Because currently, the 'date' field is only loosely coupled to
the 'author', 'branch' and 'changelog' certs. If there are multiple commits
(e.g. in case of a clean merge), you can only guess by looking at the signers
what certs belong together.
Hm.. yeah, I was jus
Thomas Moschny <[EMAIL PROTECTED]> writes:
> Markus Schiltknecht wrote:
[...]
>> Instead of trying to merge those certs together, I'd rather try to
>> increase locality of those certs in the database as well as during
>> netsync. That way, all certs would benefit, instead of only those which
>>
Markus Schiltknecht wrote:
> Thomas Moschny wrote:
> > Every cert should probably carry an 'author' and a 'date' field. Note
> > that author and signer can be different.
>
> Uh.. why would you want to merge in a date field?
Because currently, the 'date' field is only loosely coupled to
the 'autho
Thomas Moschny <[EMAIL PROTECTED]> writes:
[...]
> This would leave us with currently four pre-defined cert types: 'commit'
> resp. 'commit-message', 'branch', 'tag' and 'suspend'.
And test-result.
Maybe that one needn't be predefined, though.
___
Hi,
Thomas Moschny wrote:
Every cert should probably carry an 'author' and a 'date' field. Note that
author and signer can be different.
Uh.. why would you want to merge in a date field?
Maybe one also wants to have a message' field, but I'm not sure what the use
case would be, and we surely
On Monday 28 January 2008, Bruce Stephens wrote:
> Probably. IIRC it's also been suggested that certs should have a
> version number. Obvious other things to fix are references to key
> and/or branch names. (And presumably tag names, if one wants to be
> able to rename tags.) Wasn't there also
Thomas Moschny <[EMAIL PROTECTED]> writes:
> On Monday 28 January 2008, Graydon Hoare wrote:
[...]
>> The changes are, primarily: [...]
>>- a sketch of the long-planned upgrade to certificates
>
> Can you explain that a bit? Is this related to the idea of creating
> combined certs consisting
On Monday 28 January 2008, Graydon Hoare wrote:
> I think it's a good branch as they go in this sort of thing. I just ran
> out of interest.
Sorry to hear that, but that's life, it seems.
> It contains a variety of interrelated new code. Anyone
> else is welcome to pick it up of course.
> The c
Hi,
Lapo Luchini wrote:
I don't think that's true, AFAIK "extracting heads" is not a single
query, it involves something closer to: getting many revisions,
verifying the cert signatures (?), creating the graph, finding the heads
of the graph.
Well, I think Alvaro's point was, that most of that
Alvaro Herrera wrote:
> There was
> some code posted that was extracting all heads and them removing the
> ones that were suspended. Or something like that. [...]
> What you're doing amount to 1 query to get the list, and
> then N queries to potentially remove each of the N results.
I don't thin
Koen Kooi wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Keller schreef:
>
> | So where lacks monotone the most?
>
> Speed. Try doing simple things like 'mtn log', 'mtn annotate' or even 'm
> tn sync' with an OE database and you start to see how badly mtn scales.
> We keep mtn
Thomas Keller wrote:
You've probably read Graydons recent message; I did and I have to say
that it made me a little sad. Not because Graydon "officially" stopped
working on the project - he wasn't doing many things lately anyways
beside the recent attempt of redoing netsync with something smar
2008/1/27, Koen Kooi <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thomas Keller schreef:
>
> | So where lacks monotone the most?
>
> Speed. Try doing simple things like 'mtn log', 'mtn annotate' or even 'm
> tn sync' with an OE database and you start to see how badly m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Keller schreef:
| So where lacks monotone the most?
Speed. Try doing simple things like 'mtn log', 'mtn annotate' or even 'm
tn sync' with an OE database and you start to see how badly mtn scales.
We keep mtn around because half the coreteam
37 matches
Mail list logo
