On Wed, 2005-01-19 at 14:04, Justin Erenkrantz wrote:
> > 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.
>
> I'm not sure how you see that as requiring an individual lock on every
> file. A WebDAV client takes a LOCK on the top-level directory with
> infinite depth and that means that no files or sub-collections can be
> modified without holding that lock first.
Correct. But it's naive to assume that the person changing the
copyrights in every file is going to be using tools which realize they
can take out a directory lock (or is going to be savvy enough to
manually take out a directory lock).
So it's still perfectly expected that no-concurrency environments would
be running into commits with lots of locks. The flaw here is quite
clearly in Apache httpd; blaming it on a lack of support for directory
locks is ridiculous.
> > 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
Right now we are sacrificing a great deal of performance over ra_dav for
the sake of a fantastical dream of interoperability with a nonexistent
class of servers. If we simply gave up on interoperability with
hypothetical DeltaV servers, we could phase out the wcprops mechanism (a
serious source of complexity as well as working-copy inefficiency), we
could have faster imports through custom-report pipelining, and we could
eventually reduce the amount of code in libsvn_ra_dav by perhaps a
factor of two.
I think there are insurmountable technical obstacles to making our
client work against a generic DeltaV server, because our client believe
in global repository revision numbers. (I don't think we fully
understand what those obstacles are, but I'm confident that if someone
sat down and thought through the problem in detail, they would hit a
wall.) But equally compellingly, from a project resource allocation
point of view, the people who believe in this interoperability are not
the people who are writing the code, so it's Just Never Going to Happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 23:02:23 2005