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