Greg Hudson wrote:
>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.
>
>
That's no worse than breaking the lock any other way.
>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.
>
>
*harrum* I'm not "inventing" new uses for locks. I'm simply telling you
how I know they're being used. For example, the decision between using
locks or ACLs for restricting access to a release/integration branch
depends on your process, and there are a multitude of those, all equally
valid. I've spent the last three months modifying ACLs instead of using
locks to block access to the release branch where locks would serve
better, because the tool in question doesn't _have_ directory locks. I
hated every minute of it.
(Before you ask, yes, I did try to get the process changed -- and the
tool replaced -- was actually hired to do so. Hollow laugh.)
>> 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.
>
>
I agree. I can't see why you'd need read hooks except for implemnting
ACLs, anyway. :-)
>>+ [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.
>
>
I mean the lookup table should be part of the FS, of course.
>> 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.
>
>
Exactly. The lookup table should be part of the FS implementation. :-)
>>+ -- 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.
>
They do.
>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.
>
>
Yes, yes! We do agree sometimes. Good. :-)
>>+ [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?
>
>
Oh, that's related to the nature of ACL processing. In the ACL itself,
you can say, "anyone can break locks in this tree"; but in the global
privilege assignment you can say, "*this* user may never break locks".
The privilege restriction overrides ACL permissions. It's sort of a mask
on the ACLs.
(Use case? "Anonymous" user with read-only access. You don't want to
have to add the read-only restriction to each and every ACL you create.
Instead, you restrict the set of access privileges that apply to the user.)
>>+ 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 guess. I'm still refining the ACL privilege list and semantics.
>>+ ... 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.
>
>
Yes, I wasn't quite clear. When the client sends a "current state" tree
to the server, it should include any lock tokens it finds in the working
copy. There can be only one of those per path, so the server can reply,
"the lock on *this* path is stale" without having to send the lock token
back to the client, or any client.
Perhaps there's an even easier way; since an "svn st -u" would list
locked files anyway, the client can notice that the lock is gone simply
by the fact that it's not marked as locked in the status/update reply.
Doesn't even have to send lock tokens to the server except on commit or
unlock.
In effect, the server generates a lock GUID and sends the token to the
client _once_, at "svn lock". The client can send lock tokens to the
server at any time.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 01:36:23 2004