[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HTTP protocol v2: single commit request, or many PUTs?

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 10 Nov 2008 07:44:31 -0800

Hunh? There is an Overwrite: header that can be used with COPY. If we
want failure, then we can use that header.

On Mon, Nov 10, 2008 at 7:43 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> I was kinda hoping we could *stop* using COPY because mod_dav enforces a
> semantic that doesn't jive with that of our RA design, namely that it
> silently permits overwrites of copy targets where our other RA layers prefer
> to raise an error. (issue #3314)
>
> A strike against the single-request approach is that our server-side
> operational logging quality severely degrades unless we move away from our
> policy of logging one line per request.
>
> Greg Stein wrote:
>> There ARE NO "turnarounds". You just pipeline a bunch of PUTs up
>> there. For all intents and purposes, it *looks* like one big mother
>> request.
>>
>> Don't forget that a commit also has COPY and DELETE operations going
>> on, too. And in the future, maybe a MOVE or two :-)
>>
>> IMO, it is easier to understand if you keep the operations separate
>> rather than glom them all into one bigass request. Those big glommed
>> requests then need to be parsed to be broken up. They also don't
>> restart very well in the face of network failure, packet drops, or
>> connection closures.
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-10 16:44:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.