three meanings of "lock"

Gareth McCaughan gareth.mccaughan at
Fri Jan 13 16:08:32 CST 2006

[This is a re-send of something I sent on 2005-12-17, which hasn't
appeared in the mailing list archives on the web and to which I've
had no reply. I suspect it got eaten by gremlins. -- gjm]

So, we have:

1. "Locking" performed by Subversion to avoid race conditions
between Subversion clients.

  | The third column will only show whitespace or an L
  | which means that Subversion has locked the directory's
  | .svn working area. You will see an L if you run svn status
  | in a directory where an svn commit is in progress —
  | perhaps when you are editing the log message. If Subversion
  | is not running, then presumably Subversion was interrupted
  | and the lock needs to be cleaned up by running svn cleanup
  | (more about that later in this chapter).       

2. "Locking" performed by Berkeley DB to avoid race conditions
between database accessors.

  | Berkeley DB requires that the underlying filesystem implement
  | strict POSIX locking semantics, and more importantly,
  | the ability to map files directly into process memory.   

3. "Locking" performed at the repository level by users to avoid
race conditions between users -- though the term "race condition"
usually isn't used in this context.

  | Many version control systems use a lock-modify-unlock model
  | to address this problem. In such a system, the repository
  | allows only one person to change a file at a time.  

These are all referred to, in the current version of the Book,
using the same words. They're generally well separated, which
is good, but readers could still be confused. 

I think this could be improved by adding a brief section,
perhaps somewhere under "Locking" or after the first use of
the word "lock" or one of its cognates, on the meanings of "lock",
and by taking a little care with terminology in places where
there's most danger of confusion. The first two sorts of lock
affect users only when something has gone wrong; we should
perhaps reserve bare "lock" for the third (directly user-relevant)
sense, call the first two "working copy locks" (or "WC locks")
and "BDB locks" or something of the sort, and provide cross-references
to the section on the meanings of "lock" anywhere that could
be especially misleading.

If this is considered a good idea, I'm happy to grab the latest
XML sources and submit a patch. Shall I? And, if so, are there
any important things I might not know, or might forget, that
would make a difference to how I do that?

(I'm not currently subscribed to svnbook-dev.)

Gareth McCaughan

More information about the svnbook-dev mailing list