[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync
From: |
Ulf Ochsenfahrt |
Subject: |
Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync |
Date: |
Fri, 02 Mar 2007 15:37:50 +0100 |
User-agent: |
Icedove 1.5.0.9 (X11/20061220) |
Thomas Moschny wrote:
On Friday 02 March 2007, Ulf Ochsenfahrt wrote:
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?
What is the problem here? During netsync, one peer (the server) can tell the
other peer (the client) about *IDs* (i.e. hashes) of all the revisions it
has, regardless of whether it is allowed to tell it about the *contents* of
those revisions? Current netsync probably cannot handle that, because it aims
at clearing out all differences between the revisions sets of both peers,
after having determed them. In the case above, the client could have only
some of the revisions it is actually not allowed to have but not all, so it
would ask the server again and again.
Consider the following case:
Branch A | B
Revision x |
You have no access to A, and both read and write access to B.
Right now, you can write a certificate stating that revision x is part
of branch B. If you have read access to B, then you can read revision x
(and all its ancestors), even if it was originally in A to which _you do
not have read access_.
Branch A | B
Revision x | x
One solution is to block branch certificates. However, you can still get
the contents of revision x. You do this by creating a revision x' that
is a child of x, and put that in branch B. Then netsync will
automatically tell you the contents of x in A, to which _you do not have
read access_.
Branch A | B
Revision x |
\|
\
|\
| x'
So, the correct solution is to block both branch certificates and
revisions that have a parent in a branch to which you do not have read
access.
However, what happens if you got revision x from elsewhere, and you want
to create x' in B?
You can do this by proving to netsync that you know the contents of x.
In fact, you should also have to prove that you know the entire history
of x, because you just effectively published it on branch B.
There's the catch. Giving a revision a branch certificate in another
branch gives allows anyone with read access to that branch access to the
entire history of that revision.
Maybe this issue will go away if we change netsync to use a dag-based
refinement, as proposed by Timothy here:
http://lists.gnu.org/archive/html/monotone-devel/2006-09/msg00124.html
And that is exactly what dag-based refinement is supposed to solve: if
you use the branch name to select a revision, then netsync currently
also selects the entire history of that revision, even if it isn't on
that branch. And if the other side didn't select the history of that
revision, then you have a performance problem.
However, that assumes that you have read access to those revisions.
Cheers,
-- Ulf
smime.p7s
Description: S/MIME Cryptographic Signature
- [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync, Ulf Ochsenfahrt, 2007/03/02
- Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync, Richard Levitte - VMS Whacker, 2007/03/02
- Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync, Chad Walstrom, 2007/03/02
- Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync, Richard Levitte - VMS Whacker, 2007/03/02
- Re: [Monotone-devel] RFE: Hard Barrier Between Branches in Netsync, Timothy Brownawell, 2007/03/03