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

Exclusive locking: how to implement in libsvn_repos?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-05-25 00:34:52 CEST

I'd like solicit opinions about a discussion I've had with ghudson.
Specifically, we're talking about this part of the locking design:


* Implement locking in libsvn_repos, not libsvn_fs. Just like the hooks
  feature, locking is an external system overlaid on top of a
  versioning filesystem.

     - Wrap all of the "write" fs functions with new svn_repos.h
       functions. Make everything call these.


cmpilato and I have been edging toward the "wrap all fs functions in
the repos layer" solution, as mentioned above.

ghudson doesn't like this idea:

   "...the libsvn_fs API is a big API, and duplicating it means our
   already large API gets even larger. Generally, libsvn_repos deals
   in larger concepts than libsvn_fs, so it seems conceptually muddy..."

ghudson feels that the cleanest design is to simply have
svn_repos_fs_commit_txn -- our current repos-level commit wrapper --
do the checks for locked files.

Of course, our immediate response to this proposal was: "are you
crazy? We need to bounce locked files *before* the client uploads
text data, just as we bounce out-of-date files early. We don't want
to let a user upload a 500MB file before discovering it's locked!"

ghudson has two (IMO) very interesting responses to this.

1. Who cares, this isn't a real problem.

   In the concurrent copy-modify-merge paradigm, it's actually
   somewhat common for users to attempt to commit out-of-date files.
   So it's a good thing that the commit-process catches the conflicts
   early on. But in the lock-modify-unlock paradigm, it's going to be
   extremely rare for someone to try to commit a file locked by
   somebody else. It's not worth massively complexifying our commit
   process for this rare situation.

   (Background: to understand why this situation is rare, look at the
   locking-design.txt document... the current client UI model being
   floated by branko, jpieper, and others involves unmergeable files
   having a 'lockable' property attached and being read-only most of
   the time. To make a file editable, users run 'svn lock' -- and
   discover existing locks before starting real work. In other words,
   the client UI will "bounce" the attempt to change a locked file
   before the work even begins. It would be very hard for someone to
   edit a file, ignorant that it's locked by someone else.)

2. Here's an alternate strategy.

   If we must bounce locked files "early", then we teach the
   libsvn_repos commit editor to check for locks. This editor is
   already shared by svnserve and ra_local. For mod_dav_svn, we teach
   its own commit editor to do the same thing; it calls the same
   libsvn_repos lock-checking function(s).
   This isn't as crazy as it seems. We already have a rule that goes
   like this:

     "If you want to be a good server-citizen, then you must honor
     hooks. Do this by using certain repos functions to create and
     commit transactions."

   And now we'd be adding a very similar rule:

     "If you want to be a good server-citizen, then you must honor
     locks. Do this by using certain repos functions to check
     committed paths against existing locks."

Anyway, if you've made it through this explanation, then I commend
you, and look forward to your feedback.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 25 00:38:46 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.