Ben Collins-Sussman wrote:
>> With no transaction-based consistency protection?
>>
>>
>
>Write to a tmpfile, then move it.
>
>
And add yet another level of file locking for multiprocess
serialization. Why reinvent the wheel if we've already invented it
_twice_ -- once using BDB, and once using FSFS?
>>>+ Will you let the admin edit the lock file behind a running
>>>+ server's back?
>>>
>>>
>
>Presumably svn_repos_fs_commit_txn(), will read/parse the locks-file
>every time it is invoked. So it happens exactly once per commit.
>
>
Oh fine. lock;parse;precheck;merge txn;update
locks;write;fsync;unlock;ouch, someone did hot backup in between...
Sounds suspiciously like something database transactions are designed to
handle. Or rather, like something the FS implementations already handle.
>> 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.
>>
>>
>
>Yes, why are ACLs related to locks? We certainly don't want to design a
>locking system that *hampers* a future ACL system, but I don't want to
>intermingle the two efforts unless Branko starts getting very specific
>about ACL design.
>
>
I've explained this before. Both ACLs and locks need a path-based lookup
table that supports tree-based inheritance. The idea is to use _one_
table for both, and a single lookup overhead for both, not reinvent the
wheel yet a third time.
[On a related note, I'm beginning to wonder why we have a separate
filesystem and repository layer. Taking stuff out of the filesystem and
putting it in the repos to keep the filesystem "clean" is weird, because
the definition of "clean" seems to shift with the wind (for example, I
suggested implementing revprop indexes in the repos layer, and ghudson
objected. Then I suggested implementing locks in the FS, and ghudson
objected... :-) And we keep duplicating APIs all over the place because
of this dichotomy. And arguing about where core FS features such as ACLs
and locking should go.
Initially, the separation was supposed to be: FS features into the FS,
repository features in repos. User identification is a repository
feature. Hooks are a borderline case. Locks, ACLs and such are
definitely FS features in my book, because they interact with versioning
semantics. Anything that requires a path and/or version-based lookup is
a prime candidate for the FS layer.]
>>>+ [+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.
>>
>>
>Agreed.
>
>
/me bangs head against wall in despair
The "where" is a note for the users, just like the "why", and does not
imply that the repository needs to keep track of working copies. If you
enable sending location info as part of the lock token (not on by
default, of course), and then move your working copy, well, that's your
problem, but the repos won't care.
We're attaching way too much importance on this "WCs can be moved"
mini-feature and using it as an argument against features that cover use
cases where moving WCs is _not_ common. I'm talking specifically of a
corporate environment where it's expected that a repos admin can list
all the locks _and_ their owning WCs to, e.g., check compliance to some
checkin policy.
Also re "lock notes": I _have_ worked -- still do -- in teams where
setting lock notes is common. We find it eminently useful because a
developer can broadcast her intention to the team. In a slightly
stricter environment (where you integrate change and configuration
management), the system will typically _require_ you to set a lock note;
or rather, will generate it from change management metadata. Etc. etc.
I can hear the "subversion is about replacing CVS for open source
projects" litany coming again...now if you insert "1.0" between the
first and second words, I'll buy it.
>>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
>>
>This sounds fine to me.
>
>
Can't argue with this, I suggested it. :-)
>>[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.
>>
>>
>
>+1. This is crazy.
>
It's this anarchistic tendency again... Let me put it this way. We, and
many others, are using subversion in an environment where developers can
be trusted to do the right thing. In such an environment, the
free-for-all-by-default principle is valid. Now, in many corporate
environments, you /can't/ trust the developers to DTRT (or the managers
don't /want/ to), and therefore this has to be a repo admin's decision.
Will you entertain the idea that we at least _allow_ changing this
property to be restricted? Or do we want to lock svn out of this
"market" by default?
There's also the issue of default behaviour. It's reasonable to require
locking for binary files but not for text files by default, and to let
people change this default -- again in a server config file. Elsewhere I
suggested a mime-type-based decision, for example.
---------------------------------------------------------------------
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:13:28 2004