On Wed, 2005-01-19 at 13:13, Ben Collins-Sussman wrote:
> 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.
Er, no. You *just* defined a use case where you'd want locks on all the
files. "I want to disable concurrency altogether" would not mean using
directory locks.
> 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.
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.
> 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.
+1
---------------------------------------------------------------------
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:55:36 2005