[Monotone-devel] RFE: Hard Barrier Between Branches in Netsync

[Ulf Ochsenfahrt]

Hi,

this was previously discussed here:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4051

and here:
http://thread.gmane.org/gmane.comp.version-control.monotone.devel/10444

So far I have been entirely unable to convince anyone that this is an 
important topic, so let me try again. Consider the following two scenarios:

Scenario 1 (myself):
I've got a database with 80 branches for 52 projects with a total of 
3763 revisions. I can subdivide these branches into roughly 10 sets of 
branches: my private branches, branches i share with my gf, branches i 
share with colleagues at work (read-only), branches i share with those 
same colleagues at work (write access), branches i share with other 
colleagues at work (...), entirely public branches, and so on.
Furthermore, I have 3 machines I regularly use for work: my home 
machine, my work machine, and my laptop, that I take with me to Oxford, 
where my gf lives. I also have a server that I use as a monotone server 
where all branches are stored as well, and that I can access from 
anywhere - and so can the other people who have access to those branches.
Putting these sets of branches into different databases (as is currently 
recommended) would require me to split the projects across 10 databases, 
forcing me to maintain 40 databases across 4 machines with the same 
number of trust settings.
Ugh!

Scenario 2 (sourceforge):
Let's for a second assume that sourceforge would wish to provide 
monotone access for all projects and developers. The current monotone 
recommendation would be to set up one database per project, meaning that 
sf would have to run 142766 instances of the monotone server on 142766 
different ports.
Yikes!

Proposal:
I propose that netsync is modified to provide hard barriers between 
branches on write access. That is, when writing certificates and 
revisions, it denies write access to those branches that the 
authenticated user has no write access to. It also denies operations 
that would require read access to branches that the authenticated user 
has no read access to.
If a revision is transmitted that is the child of a revision that the 
user does not have read-access to, then netsync has to transfer that 
revision as well, but it is not written to the other database (because 
it is already present there).

Discussion:
This proposal would have multiple effects on how netsync works.

First of all, it would allow much stricter control over who can write 
what to the database. This is useful because it solves the main problems 
that arise in the two scenarios described above, making it possible to 
keep private and non-private branches in the same database.

Second, it would lead to (potentially) lower efficiency. If the user has 
new revisions which are children of revisions that he does not 
officially has read-access to, then he has to also transmit the parent 
revisions, even though these may already be present in the other 
database. I do not expect that this would happen often. One could even 
argue that this can only happen when the access rights are incorrectly 
configured. After all, how can a user know of a revision that he doesn't 
have read-access to?

In my opinion this proposal is orthogonal to the concept of trust 
settings. Trust settings allow control over what people read from a 
database that contains all sorts of things, and these rules allow 
control over what people write to a database that contains all sorts of 
things.

What do you think?

Cheers,

-- Ulf

smime.p7s
Description: S/MIME Cryptographic Signature