Re: DAV lock-token decisions. (please read)

On Wed, Jan 19, 2005 at 01:48:06PM -0600, Ben Collins-Sussman wrote:
>...
> 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.

I'd vote for as much compat as possible, but will defer on this since
I don't have time to actively code to support my desire :-(

That said, should you go with an extension of some kind:

> 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.

No need for a custom method. I think you should be able to marshal
them directly into the merge report. A third-party DeltaV server ought
to simply ignore it.

> * 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.

The new client would insert lock tokens which would be ignored by the
old svn server. Note that the DAV:merge element allows for any child
elements. mod_dav(_svn) definitely ignores that stuff right now, so
the server and client are completely prep'd at this point for a
negotiated feature here.

> AFAIK, we have no scalability limits with commits right now.

Yes, we do. The client loads a ton of stuff into memory. The client is
*not* streamy.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org