All developers should read this mail, because it's not about DAV
trivia. It's about design choices.
Julian: thanks for the feedback regarding multiple "If:" headers. But
I still think we have a scalability problem.
ra_dav (just like ra_svn) needs to send an entire hash table in the
final commit request. The tokens are used by svn_fs_commit_txn(), and
the locked paths are also potentially unlocked after the commit.
In ra_dav, the hash table would be sent in one (or many) If: headers,
and look something like this:
If: <http://localhost/svn/testrepos/svn_fs.h>
(<opaquelocktoken:089de92f-faed-0310-8bae-a5a8e69883c3>)
<http://localhost/svn/testrepos/svn_opt.h>
(<opaquelocktoken:318e4a30-faed-0310-b7c8-8ca78f5e65bf>) [...]
The problem is that apache defines a default 8K length limit per
header, and a default limit of 100 headers per request. These defaults
are changeable in httpd.conf, but still there's an arms race here:
"Oh, the commit failed? just tweak your httpd.conf. Oh, it failed
again? Better increase those limits!" This is a sure-fire way to
irritate administrators... while forcing them to (possibly?) make their
apache less secure. It reeks of badly written software.
The real problem here is that we're trying to send a potentially
unbounded amount of data in container of finite size.
And the use-case isn't absurd. There will definitely be corporate
users of Subversion who will want to disable concurrency altogether.
They'll keep their entire tree in a read-only "svn:needs-lock" state.
And when somebody needs to change the license on all 1000 files,
they'll lock all of them in a working copy, edit them, and 'svn
commit'.
Justin Erenkrantz made a good point in IRC: it's not really DAV that's
flawed here. A real DAV client would lock the whole directory and use
a single token for everything. But we decided to punt on
directory-locks, and in some sense we're now paying the price.
Mike Pilato has an idea, though I'm not sure how I feel about it. He
thinks that if the final MERGE request gets an error regarding header
limits, it can re-try the commit using a new custom REPORT request.
Kinda icky.
Feelings? Should I just bite the bullet and implement a new custom
REPORT? I wonder if ra_dav shouldn't just use the new REPORT-type
whenever lock-tokens are present.
(Meta comment: we've generally shied away from creating custom
protocols. But more and more, I think the dream of "svn should be a
compliant DeltaV client" has fallen by the wayside. The real priority
has become, "mod_dav_svn should be a compliant DeltaV server, or at
least a compliant DAV server" -- because there *are* DAV clients in the
world being used by many people. But will the svn client ever talk to
some other DeltaV server? Not likely. Mike Pilato's idea preserves
this dream to some extent, I guess.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 19:15:12 2005