Locking proposal: The update-and-lock model

Hi everyone,

I just read the locking design document. It's nice to see that work is in progress on this feature.

Please consider the update-and-lock model outlined below. In essence, this approach treats "lock" as a special kind of update and "unlock" as a special kind of commit.

I believe the approach has several advantages; i.e. it doesn't require state to be kept in the working copy, it is easy to grasp for the end user, and I imagine that this would be easier to implement than the current proposal (although I certainly doesn't know all the internals of Subversion.) I also believe the approach works well in recursive and non-recursive modes. There are probably issues I haven't considered...

INTRODUCTION

Here's how I think it would work from the client perspective:

1. Client #1 does a svn lock <resource>

   What happens is that the resource is updated

   (same as svn up). But the server also locks

   the resource (e.g. sets a flag in a locking table.)

2. Client #2 attempts the same command on the same
   resource, but the server says "nope" since the
   lock-flag is set on that resource.

3. Client #1 does a svn unlock <resource> which

   commits the changes. The server also changes the
   status to "unlocked" as part of the transaction.

4. Client #2 does a svn lock <resource> and now
   he gets the latest changes AND the lock.

So essentially, locking is just a special kind of update and unlocking is just a special kind of commit.

LOCK OWNERSHIP

While owning a lock, you may commit and update the resource using the normal svn commands (yes, updating doesn't make much sense as nobody else have access to the resource; committing *does* make sense, since others can do svn up but not svn lock... that is, you can ship changes to the repository without releasing the lock.)

If the lock owner does a commit on a higher-level directory, everything works as expected: the lock flags are preserved in the database until he or she issues the unlock command. Unlocking on a non-locked resource is simply the same as a regular commit. This is nice because you can unlock a directory tree having a mix of locked and non-locked resources; everything is committed and the lock flags are preserved.

Attempting to do a svn up on a locked resource => no problem; the lock owner may in fact have committed changes without releasing the lock.

Attempting to svn commit on a resource locked by someone else => you get a "resource is locked" message.

RECURSIVE LOCKS

Same as with svn up and svn ci, I guess, which means that the lock actually locks the sub-tree (a good many data structures works like that in concurrent environments.) Of course, there is a non-recursive option as with the regular update and commit commands (hmmm, not sure what the best default is for locking - probably the other way around.)

LEASES

I would also like to see timeouts on locked resources, but that may well be a version 2 feature(?) But generally, I think people should *lease* a precious resource like a lock, simply because people forget stuff. They tend not to forget so easily if forgetting has a price... read on.

For instance:

svn lock -t 4h <resource> // locks the resource for 4 hours.

svn lock -t 0 <resource> // locks the resource forever

Also, the following admin command is required, IMO:

svnadmin unlock <resource>

...which forces the resource to be unlocked. From the lock owner's perspective, this has the same effect as the lease timing out (more on this later.)

Users could also be allowed to attempt forced locking:

svn lock --force <resource>

...which means the user takes over a lock, given he has permission to do so.

Now, what happens if the lease times out, or the administrator has done a svnadmin unlock? First of all, the resource is free for others to lock or commit on. Next, the original lock owner now suddenly has a non-locked resource. If he has changes to commit, he may be lucky: nobody has committed conflicting changes. Or he may not be so lucky, so he has to manually merge/fix up after regaining the lock.

At any rate, he DID lease the lock so it was his responsibility to commit before the lease went out.

On a per-repository basis, the default length of the lease should probably be configurable (even to infinite - some like it that way, I guess.)

SYNTAX

Syntax for the lock/unlock commands:

svn lock <options> <resource>

Valid options:

    -r [--revision] arg : revision

    -t N[m|h] : lease length in minutes or hours

    --force : attempts to force lock ownership

    -N : non-recursive

    --username arg : specify a username ARG

    --password arg : specify a password ARG

    --no-auth-cache : do not cache authentication tokens

svn unlock <flags> <resource>

Valid options

    -m [--message] arg : specify commit message ARG

    -N : non-recursive

    --username arg : specify a username ARG

    --password arg : specify a password ARG

    --no-auth-cache : do not cache authentication tokens

I actually believe all the svn up and svn ci options apply since lock/unlock are simply variations of the respective commands.

CLIENTS

About clients: I guess it would be nice to see "lock" icons in visual tools like "TortoiseSVN" (which I really like) and a lock-status column for "svn status" without having to query the server for status. Perhaps locking/unlocking should automatically set props for this? IMHO, this is not an important feature. It adds complexity and actually isn't very useful if you think about it.

Best regards,

Stein Roger
Received on Wed Jun 16 20:02:55 2004