On Wed, 2004-05-26 at 10:38, Greg Hudson wrote:
> 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.
Ouch, that *is* argument against directory-level locks. But I'd like to
temporarily table this issue, and save it for a separate thread.
> 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.
+1 from the Chicago folks. For our initial design, this should be the
only place where we check for locked files. See the other mail thread
as to why.
> 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.
Hm, yah, it would be kinda bad to make libsvn_repos unconditionally
depend on BDB.
>
> > + [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?
Why not?
> With no transaction-based consistency protection?
Write to a tmpfile, then move it.
> > + 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.
> 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.
>
> > + [+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.
>
> 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.
> (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.)
Like the whole 'directory-lock' concept, let's discuss shared locks in a
separate thread.
>
> [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. Users can manually tweak a file's svn:mime-type
property to control whether a client tries to do contextual merging. In
this same exact spirit, users should be able to set a property that
catergorizes a file as "something that needs locking".
(Eventually, when we have server-side config files that are "broadcast"
to clients, admins can use auto-props (or something similar) to set
global policies about which files are lockable.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 26 19:45:33 2004