Why are we discussing locking design in a file, instead of on the list?
I can see the benefit of recording the outcome of a conversation in a
file, but not of holding it there. So, I'm going to have my part of the
discussion back here on the list.
On Wed, 2004-05-26 at 02:46, brane@tigris.org wrote:
> + [How about depth-0 directory locks? The use-case is to protect
> + dir props only; useful since those are not merged. --brane]
So, before we go wild with directory locks and depth indicators,
remember that locks don't interact well with our operational model.
We're going to run into corner cases like: I lock a file in a working
directory, make a copy of it, and then unlock it in one of the working
copies; the other one erroneously believes it holds a lock.
Because of that mismatch, we're probably best off keeping locks simple
("protect unmergeably files"), and not imagining new uses for them like
release branches (which are better handled through acls) and property
protection.
> read and write -- because then we'd open the door to
> implementing 'read hooks'.)
As an aside, I talked to Ben about this, and I think it's based on a
poorly-conceived and vague plan of how read hooks might be implemented.
So we shouldn't consider 'it will get us closer to read hooks' as a
motivation.
A better plan, in my opinion, is to have svn_repos_fs_commit_txn compare
the changed-path list to the lock table and reject the commit if there
are any files locked by a different working copy.
> + [Looking at this again, I find there's one big problem with using
> + the repos layer for this. It means the lock table has to be
> + exposed through the FS API.
I have no idea what you mean. here.
> How should this be implemented? As a separate BDB table managed by
> libsvn_repos? That would certainly scale, but then it might create
> - NFS problems, etc. Another idea is to use an XML file (parsed once
> + NFS problems, etc.
> +
> + [Huh? What NFS problems would it create that the repository doesn't
> + already have? Well, really. --brane]
So, Ben was theorizing that libsvn_repos could, without the help of
libsvn_fs_base, open a BDB table and use it. That's of course totally
unacceptable; we have two fully functioning FS back ends now, and one of
them isn't hamstrung by Berkeley BD's limitations.
> + [Please don't even think of anything but a FS-backend-specific
> + lookup table. Will you rewrite some text file every time a lock
> + changes? With no transaction-based consistency protection?
> + Will you let the admin edit the lock file behind a running
> + server's back? And more to the point, will you take the penalty
> + of keeping the whole lookup table in memory after we add ACL
> + lookup to it and suddenly find that 50000 ACLS are no small
> + thing? *shudder* -- brane]
Who says we're oging to put ACLs into the lockfile? I'm okay with doing
this if it happens to work, but I'm not okay with loading down the
locking design with the ACL system's requirements.
Why do we need transaction-based consistency protection?
> + [+2. Also think about optinally adding the client name and local
> + path to the locked file to the token (not only 'who', but 'where')
Ick. Repository doesn't keep track of working copies. That arrow only
goes one way. Otherwise moving working copies around becomes
inadvisable.
> + -- useful info in an in-company team. Also a note, commit-log
> + template if you will, which could be used to describe the
> + reason for the lock to other users. So not only 'who' and
> + 'where', but also 'why'.
People may find this cumbersome; I don't think other version control
systems generally have it. I'm not opposed to it unless (deep breath)
asking for a lock rationale is not the default unless specified by the
file's svn:lock-required property.
> + [Um. Only the lock owner (and an admin, yes) should be able to
> + remove a lock. Therefore a lock token should be required by
> + default. You could overroide that with "svn unlock --force".
> + Then after we add ACLs, there will also be a 'break locks'
> + global privilege -- brane]
Why a global privilege? Why not a local one?
Ben's idea was that the repository will look at the username to decide
if you own the lock. But I don't see the situation quite the same:
svn unlock file
--> transmit lock token, fail if no lock present with that token
svn unlock --force file
--> don't transmit token, always succeed if my username owns the
lock, possibly succeed (based on ACLs) if someone else owns the
lock
(If we allow multiple locks on a file, an idea which I consider really
bizarre, then there are some more corner cases to consider in the second
case.)
[Regarding the svn:lock-required property:]
> + [I suggest that this should be a read-only liveprop whose
> + value is implied by server-side configuration, and can't
> + be modified by the client. This is a repository policy,
> + not a user decision. -- brane]
So you need admin privileges to set up an unmergeable file? That's
dumb. If the user wants to manually unset the svn:lock-required
property in order to evade a lock, that's akin to rebuilding the svn
client to ignore it. We can't stop them, so there's no point in making
it harder at the expense of increased user-visible complexity.
> + Now if you _really_ need it, you can do "svn lock --force" to
> + steal the existing lock. Again, later on, the ACL can tell you
> + if a) you can steal locks at all, and b) you can steal other
> + people's, not just your own. -- brane]
I was thinking you'd do "svn unlock --force" followed by "svn lock", but
that's a bikeshed. No need to have two levels of ACLs, really; stealing
or cancelling your own locks is not an access control issue, and should
always succeed.
> + ... I suggest the update... should include lock tokens...
> + Oh by the way, all of this implies that the server never
> + transmits the lock GUID to anyone once the lock token has been
> + sent to the owner after an "svn lock", otherwise you open the
> + door to lock spoofing -- _not_ a good idea! --brane]
These things seem to contradict each other, so I think I misunderstood
the first part.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 26 17:38:48 2004