[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking design (was Re: svn commit: r9885 - trunk/notes)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-05-26 19:41:32 CEST

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.


> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.