[Monotone-devel] Project separation

[Thomas Keller]

Hi all!

I already brought up the idea on IRC some time ago - I am looking for a
way to restrict allowed incoming revisions on the server-side. No, I
don't plan to go towards the complexity of policy branches, which Tim is
working on for quite some time already, but I'm simply looking for a
simple way to keep different project trees separated in different
databases. (Guess what I'm talking about, right, our IDF setup!)

Our merkle sync algorithm right now is solely based on branches -
whatever revision has a certain branch name attached, gets transferred,
including all of the needed history. So in theory all you need to do is
attach a wrong branch certificate on a revision of a completly different
tree and create some merge chaos (sure, only temporary, until somebody
suspends the wrong head).

So what I maybe headed for was some notion of a "origin" cache which all
of our revisions and certificates could get. This could be a simply the
root revision of a project which separates different project trees from
each other and which is just added as token to every issued cert and
every revision.

The merkle trie algorithm would now take this origin into account:
Before the actual changes are determined, both nodes agree at first for
which origins they want to change contents for. By default all origins
are taken into consideration, but people could overwrite this setting
per database with a specific variable. (Yes, this would also mean that
you could pull "net.venge.monotone{,.*}" into your monotone-only
database and you would really get all monotone branches, and not the
guitone, usher, tracmtn, debian, et cetera ones unless wanted!)

Now that the origin agreement lead to a specific set of revisions and
certs on both sides (keys are not restricted by this), the normal merkle
algorithms would apply to find out what actually needs to be transferred
to either side.

I haven't looked at the actual implementation (this would certainly
require a netsync flag day) and I have a vague idea how this "project
marking" for certs and revisions could be done in a space-efficient way
(by using locally unique identifiers which map on the global unique
ones), but I think it should be doable.

One particular issue could however be the handling of merge_into_dir -
here the algorithm would probably leave out history of one side of the
merge when this side is prohibited to be synced. I have no immediate
answer how to solve this...

Opinions?
Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature