Re: [Monotone-devel] Re: [RFC] Monotone NETSYNC Hook Extension & Abstraction Layer

[Ralf S. Engelschall]

On Wed, Oct 03, 2007, Pavel Cahyna wrote:

> On Sun, Sep 23, 2007 at 08:02:46PM +0200, Ralf S. Engelschall wrote:
> > On my road of trying to adopt Monotone for use in my various larger
> > Open Source projects like OSSP, OpenPKG, etc I've last week worked on
> > an important issue (at least for me) which perhaps looks strange to the
> > "maximum distribution is everything which matters" guys in the VCS camp:
> >
> >    How to best combine the developer-requested distributed VCS nature
> >    of Monotone with the central ACL nature required at the "master"
> >    repository of those projects?
> >
> > To get you an impression how "deep" the problem is we try to solve
> > here: we want that the developers can use full distributed VCS outside
> > the central repository. Nevertheless, they have to fulfill a mandatory
> > contributor agreement (to protect the licensing, etc) which especially
> > means they are allowed to propagate/merge/pluck only revisions within
> > a particular branch tree (e.g. "openpkg.*") and inside this tree only
> > developers who have signed the contributor agreement are allowed
> > to commit their stuff. As long as a developer is fulfilling these
> > constraints he will be able to share his revisions (which indirectly
> > usually carry the revisions of others due to merging) with the master
> > repository (from which official release tarballs and packages are
> > rolled). If he breaks out of these constraints, he is _forced_ to stay
> > out at all.
>
> I find such server-side policy very interesting. Can you also restrict all
> revisions accepted by the server to those branches (e.g. openpkg.*) by
> mandating that all revisions accepted via netsync have this branch cert?

Yes, with the currently implemented queued database updating procedure
one can restrict revisions to those having a branch cert for a
particular (set of) branch(es). But keep in mind that to not break the
revision ancestor tree one usually also have to accept revisions which
have _NO_ branch cert at all. This happens if someone merges between
branches and then later uploads just the requested branches. Then the
revision is uploaded, but not the corresponding certs.

                                       Ralf S. Engelschall
                                       address@hidden
                                       www.engelschall.com