Re: [Monotone-devel] Re: nuskool & certs created after a revision

[William Uther]

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         :-}