[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: nuskool & certs created after a revision
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Re: nuskool & certs created after a revision |
Date: |
Sat, 3 May 2008 08:37:27 +1000 |
On 02/05/2008, at 4:46 PM, Graydon Hoare wrote:
The difference in our methods then consists of how these sets are
sync'd. I was thinking of using the revision DAG structure. You
were thinking of introducing a new parallel DAG structure based on
cert creation times. Both use a nukool-like algorithm over that
structure.
Yeah, but your plan requires recomputing all the descendant
synthetic hashes and re-running the sync algorithm for each cert
that's transmitted. That will scale as the product of the size of
the unreconciled set of certs and the average depth of them in the
history graph. Not a pretty number. And the sync algorithm itself
involves different parameters for searching and reconciling nodes in
the sync'ed graph.
I know. :(
If you store the certs in buckets and stick them in a synthetic file
tree, you'll calculate what to send using a single gsync pass --
just like the normal revision graph -- and reuse all the existing
revision- and file-syncing machinery, unmodified; you'll just run a
post-process that inspects the pseudo-files that were transmitted
and updates the certs in the database from their contents. All you
need to write is the code to synthesize the tree, the code to run a
(simple union) merge, and the code to run the post-sync digestion of
the files.
Yes, but its ugly :)
If I had to choose right now, I'd do it your way. But I'm still
trying to think of a better solution.
IMO this is much less work, and less tangle to debug. But I guess
I'm not doing it, so ... the advice is only worth the electrons that
carry it :)
I'm not doing it either...
"I love work, I can watch it for hours"
Will :-}
[Monotone-devel] Re: nuskool & certs created after a revision, Lapo Luchini, 2008/05/02