[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] RFE: Hard Barrier Between Branches in Netsync
From: |
Ulf Ochsenfahrt |
Subject: |
[Monotone-devel] RFE: Hard Barrier Between Branches in Netsync |
Date: |
Fri, 02 Mar 2007 13:10:10 +0100 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
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