three meanings of "lock"
Gareth McCaughan
gareth.mccaughan at pobox.com
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