Okay, after a day's worth of discussion and triage, cmpilato and I have
come up with a plan. Hope this doesn't rub anyone the wrong way.
We did some experiments. We completely disabled the ability to create
lock-null resources in libsvn_fs. Then we put up an authn-protected,
autoversioning repository and tried to stress-test as best we could.
We tested a bunch of DAV clients: MS Office 2000, OSX, Win2k
Webfolders, WinXP webfolders. These are the most popular DAV clients,
the ones most likely to take advantage of our new
locking/autoversioning features.
What we discovered was that MS Office *does* require the ability to
create lock-null resources. This is pretty big deal. We've been
striving to make autoversioning something really useful, and this is a
major DAV client. A lot of people will be annoyed by this.
So here's what we'd like to do for svn 1.2:
1. fully support lock-nulls in the server:
- libsvn_fs supports them already
- LOCK nonexistent-URL
- UNLOCK lock-null-URL
- PROPFIND lock-null-URL
- PROPFIND on parent shows lock-null children
We currently support everything in that list but the last
little bit. Mike Pilato is going to re-do the BDB locking tables to
emulate FSFS's system, then add a depth argument to svn_fs_get_locks().
(See my other email about this). It means that it will be a little
bit slower to do a depth-infinity fetch of locks, but it also means
that it will be *reasonable* to do a depth-1 fetch of locks, and thus
easily discover lock-null children. If we don't make this lock-table
schema change now, we'll be stuck with it till 2.0. So we want to get
it right the first time; we won't be able to casually add this last
feature in 1.3.
2. punt on locknull support in the client.
- 'svn st -u' will not show lock-nulls.
- 'svn info URL' will not show lock-nulls.
- 'svn ls' will not list lock-null children.
- 'svn lock/unlock URL' won't work on nonexistent paths.
- 'svn lock wcpath' won't work on schedule-add paths.
In theory, we've been worried about the scenario where a DAV
client creates a lock-null resource, and then this starts to effect svn
clients adversely. (e.g. an svn client tries to delete a directory,
gets a locking error, but can't see the lock!) But our epiphany today
was that in *practice*, lock-null resources don't last for more than a
microsecond. The probability of affecting an svn client is miniscule.
So we'd rather punt on these client features, and simply leave the door
open to add them in svn 1.3 if there's demand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 16 23:38:33 2005