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 | tommyd3...@jabber.ccc.de | 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
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel