[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: What's the plans for cvs_import?
From: |
Derek Scherger |
Subject: |
[Monotone-devel] Re: What's the plans for cvs_import? |
Date: |
Wed, 04 Aug 2004 20:42:33 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040602 |
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
[Monotone-devel] Re: What's the plans for cvs_import?, Richard Levitte - VMS Whacker, 2004/08/03
[Monotone-devel] Re: What's the plans for cvs_import?, Richard Levitte - VMS Whacker, 2004/08/03