On Jan 19, 2005, at 1:04 PM, Justin Erenkrantz wrote:
>
>> I think we should totally give up on having our client act like a DAV
>> client, and use custom reports whenever we have the slightest reason
>> to
>> do so. (Modulo compatibility issues, of course.) Our client will
>> never
>> work against a generic DAV server, so there's no value in it.
>
> I disagree completely. -- justin
No DeltaV server yet exists to work with. And if someday it *did*
exist, we'd have do a complete rewrite of ra_dav to interoperate...
probably using serf instead of neon so that we can do pipelining,
removing our need for REPORT requests on checkout/update/switch/diff.
And we've handwaving over all the svn concepts that *don't* map to
DeltaV... don't get me started. That's a whole separate thread.
So in my mind, we're weighing the risk that it will be 1% harder to do
a total rewrite of ra_dav someday to work against a hypothetical
nonexistent server, versus the *definite* cost of getting occasional
complaints from svn 1.2 users.
My plan is this:
* If tokens aren't present, keep on doing final commits via MERGE.
The server will never forget how to do a MERGE. If tokens are present,
marshall them via custom method, and get back the same response-body
that a MERGE would have produced.
* An old client won't use locks, and will keep sending MERGE requests
to new servers. A new client might try to send the custom method to an
old server, which will be rejected. But that's fine, since the old
server couldn't use the locks anyway.
AFAIK, we have no scalability limits with commits right now.
Deliberately implementing limits (even ones tweakable by httpd.conf) is
just irresponsible, considering nobody in the world cares but 4
theoreticians (me, jerenkrantz, gstein, julian).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 20:49:19 2005