On 9/11/06, Timothy Brownawell <[EMAIL PROTECTED]> wrote:
...what happens if someone makes a parentless commit with that branch name but a different policy branch, then merges that in with merge_into_dir?
Any time you merge, the policy of the branch you're merging *into* applies. Again, it has to be that way or you break the security model.
> In my scheme, you cannot have identically named branches under > different policies on the same netsync server, and I think this is a > feature. (Really, best practices are for branch names to be globally > unique - hence "net.venge.monotone.whatever" instead of just > "whatever" - but we can't enforce that.) Ah. See, I was thinking it would be one policy branch per project. So the project gets a branch namespace, which is then attached to the db's branch namespace either by the suggested prefix (given in the policy branch) or by a config file (much like mount and filesystems...). You seem to be saying multiple policy branches per project, and only one project per db (or at least, no *hostile* projects sharing a db)?
Hm, not quite ... All I'm saying is that you shouldn't have to tell "mtn ls branches" which namespace you're in. Two projects can have separate policy branches and share the same database as long as they can agree on a partition of the branch namespace. For instance, one could have botan.* next to monotone.*, and have different policy branches for both. Two rival development teams for the same project can do the same, again as long as there's enough civility that they can agree on a partition (netbsd.*, openbsd.*) Only when they can't get that agreement is it necessary to have multiple databases. It might, in this context, be useful to have a mechanism whereby all the branches in database A get a prefix applied to their names when syncing with database B (so A->a.b.c == B->foo.a.b.c) -- very much like unix filesystem mounts -- but I would hold off on implementing such a feature until there's user demand. It is also the case that a project can have multiple policy branches if it wants to have multiple classes of developers, but that's orthogonal. zw _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
