[Monotone-devel] Re: Re: What's the plans for cvs_import?

[graydon hoare]

On Tue, 03 Aug 2004 21:59:01 -0600, Derek Scherger <address@hidden> wrote:

> some of my local.monotone.* branches start with a new branch cert on an 
> existing manifest
> in the net.venge.monotone branch and I'm wondering whether my local certs will 
> be visible
> over netsync if I'm only serving the net.venge.monotone collection. I don't 
> think they
> should be?

the exact algorithm for composing a collection is:

  let B = all branch certs which match the collection prefix
  let M = all manifests mentionned in certs in B
  let C = all certs on manifests in M
  let K = all keys used in certs in C

then we share two merkle trees, K and C. netsync decides what else to pull
(files, manifests) based on analysis of certs, which form the "backbone" of
the information it's transferring.

the affect of this is that if manifest X has a branch cert net.venge.monotone,
and you add another branch cert on X for local.monotone.foo, it will be synced
when you publish net.venge.monotone anywhere. certs on subsequent manifests
(solely in local.monotone.foo) will not be published.

this algorithm is probably going to change:

 - certs will (mostly) apply to revisions rather than manifests, and your
   new commit (by making a new revision) will always be separate from the
   existing revision, even if the manifest is the same. I'm not yet sure if
   I ought to still support manifest certs for test results (which ought to
   be the same across multiple revisions with the same manifest); if so that
   would require sharing a third merkle tree.

 - in theory I can also tell it to filter out branch certs in C which don't
   match the initial collection name. that's probably desirable.

 - I'm thinking of removing the concept of a collection altogether, and
   just letting people serve branches. one less concept to think about for
   the simple case. I'll probably include the possibility of serving a glob
   (literally "net.venge.monotone.*") in order to retain the current
   capability for clients to add branches on the fly.

in addition:

 - the secondary tree of keys can potentially go away, and the merkle trie
   structure can actually be simplified a bit.

 - I'll probably start building the merkle trees in memory alone, and
   killing off the disk-based use of them. it's one more bit of state I'd
   prefer not to maintain, and doing it in memory paves the way for
   "live" randomization of the structure.

> presumably, if some of my local branch stuff works out I should be able to put 
> it into a
> net.venge.monotone.something branch where it will be available but I wonder if 
> there might
>   be problems with this or a better way of doing things...

no, that sounds good.

-graydon