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

[Derek Scherger]

graydon hoare wrote:
> 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

"it" being the manifest or the second cert? I'm pretty sure the manifest will be synced 
but it sounds like the cert will too which is probably undesireable.

> 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

so are you going back to allowing commits (and creating new revisions) that don't include 
any manifest changes then? ;)

>    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.

certainly sounds like it, or you'll be getting things like my silly branch certs

>  - 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.

this sounds pretty good

> 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.

I think I've noticed that if I commit a new branch directly to the database file that a 
server is serving from it is not visible to someone pulling from that server until the 
server is restarted. Are the merkle trees built in the database when the server starts or 
when a new connection opens?

> > 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.

what I'm wondering about is this:

suppose we have A -> B -> C in net.venge.monotone
            and A -> X -> Y -> Z in local.monotone.foo

suppose I then cert Z into net.venge.monotone which leaves net.venge.monotone not merged 
and with 2 heads C and Z

will trying to merge resort to the 2 way merge because the ancestry of Z is not part of 
the net.venge.monotone branch?

if we then sync and you don't get X and Y does this do anything particularly nasty to the 
ancestry graph?

--
Cheers,
Derek