We're making great progress toward Subversion 1.1. Just so we can all
feel good, here's a list of "big" accomplishments so far:
* We've essentially finished issue 1093 ("diff follows renames").
* We have a localization framework in place with volunteers writing
.po files. How sweet.
* We're in the process of finishing an API to fetch library
versions and compatibility info.
* (bonus!) 'svnadmin dump --deltas' / 'svn export --native-eol'
* (giant bonus!) We have a new native-filesystem repository backend.
The last "big" 1.1 feature is reserved checkouts, a.k.a exclusive
locks on files.
Why Locking?
------------
Our users are screaming for this feature. People often need to keep
unmergeable files under version control. The concurrent
copy-modify-merge model breaks down when somebody discovers that
they've wasted two hours editing an unmergeable file that somebody
else was also editing. Granted, that scenario can be avoided by
increasing communication between the developers; but then shouldn't
the version control tool help them communicate? In an ideal
situation, the version control system would have prevented the the
second user from even starting the incompatible edit. (CVS has a
partial communication-solution in place, but I'm sure Subversion can
do better.)
Another outcome of this feature is that it means that mod_dav_svn will
finally understand the LOCK and UNLOCK webdav requests. This means
that ordinary "dumb" dav clients will finally be able to open & edit
files directly from a mounted repository. This is a huge deal to some
people: true transparent versioning, much better than our
current half-working 'autoversioning' hack.
History
-------
Back in 2002, several Subversion developers met face-to-face at
Apachecon and drafted a spec for adding exclusive locks to libsvn_fs.
It's been sitting in /trunk/notes/locking-plan.txt. Since then, the
Chicago guys have been rereading it and trying to refine it further.
Meanwhile, Branko has privately come up with an alternate design for
libsvn_fs locking (which I think involves adding ACLs.)
But I'm tired of waiting for both parties to "polish" perfect specs.
If the two designs are going to butt heads inevitably, I'd rather do
it out in the open right now. There's no need to wait for complete
designs before hashing out differences.
The Plan
--------
I'd like to have two separate discussions on this list. Yes, that's
right, two discussions:
1. How do we add exclusive locks to libsvn_fs?
2. How do we present locking features to the user?
The reason I want these to be separate discussions is because topic #1
is guaranteed to halt in a finite time. :-)
Seriously, it's *very* easy for locking discussions to backslide into
endless UI discussions. The bikeshedding becomes enormous. It kept
happening to us at Apachecon, and we had to forcibly pull ourselves
out of it and focus on just libsvn_fs design.
There's no dobut that the second discussion will have to happen
eventually, but doesn't need to happen *now*. My gut feeling is that
once we've defined a UI, all of the code changes needed "between" the
user and libsvn_fs will fall into place.
At the moment, however, I'd like to stay focused on libsvn_fs design.
And I'd like the design to be doable in Subversion 1.1. This means
* no schema changes
Adding new tables is fine; repositories can auto-upgrade
themselves, just as the 'uuids' table was magically added. But
we can't make any changes that require dump/load.
* adding new libsvn_fs functions
We can add new functions to svn_fs.h, but cannot change existing
ones.
My next mail will give an outline of the fs changes the Chicago guys
have been contemplating. My hope is that Branko will respond with his
own design. The discussion should prove interesting, because ghudson
and jpieper have libsvn_fs freshly in their minds. This means two new
active voices on this topic. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 19 21:46:12 2004