[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] nuskool & certs created after a revision
From: |
Lapo Luchini |
Subject: |
[Monotone-devel] nuskool & certs created after a revision |
Date: |
Fri, 02 May 2008 02:08:27 +0200 |
User-agent: |
Thunderbird 2.0.0.12 (X11/20080312) |
Today I had a quick chat with Markus and Derek about nuskool and
actually went and read gsync.cc and -to my surprise- I have to agree
with 'em when they said "it's easy, really!".
I didn't really thought so at first.
OK. It transfers the DAG oh-so-nice, and cleverly so too. Then they told
me about the problem with certs: either they are sent together the rev
they refer to at once, or they never get sent later as the rev is never
sent again.
And I proposed: what if a cert has a new 'time of creation' attribute
containing the ID of one head at the time of creation (plus the ID of
the revision they refer to, of course!).
This way every time I send a revision I send not the certs that refer to
it, but the certs that were created "at this time".
Then Dan said: if you do that way, it's ok if there's some new head to
send, but if you:
a. add a new cert (linked to the head)
b. sync -> the cert gets sent
c. add a new cert (linked to the head)
d. sync again -> the new cert DOES NOT get sent again
And to this I have a new proposal: *after* the common core is found, it
is sent each head (the "erase ancestors of the common core")
certs-value = sha1(all the certs created at the time of that node)
This way I only have, on each sync, to double-check the certs created at
the time of the frontier, which as we well know is usually composed of
only a few heads (1, 2, rarely more). Only for those head revisions on
which the "certs-value" SHA1 doesn't match, we send all the certs again
(or we may better refine, but they're usually little anyway, and it's
only to be done on a few heads at most!).
The main "con" to this, except the small bandwidth overhead", is that
each cert gets bigger by one ID size (both "referring ID" and "time
ID")... so I wonder if there's a better way to avoid that; but that does
at least *seem to work* to me.
(of course, it seemed to me to work also without this final "frontier
check", until Dan made me see the problem :P)
To all the interested people, I have only to say: nuskool doesn't bite,
take a look at it... verily! =)
Lapo
- [Monotone-devel] nuskool & certs created after a revision,
Lapo Luchini <=
[Monotone-devel] Re: nuskool & certs created after a revision, Lapo Luchini, 2008/05/02