On Thu, Oct 29, 2009 at 4:31 PM, Branko Cibej <brane_at_xbc.nu> wrote:
> Ben Collins-Sussman wrote:
>> It's probably just the logic in the ra_dav or ra_serf client network
>> module, enforcing proper webdav (and svn?) semantics. Every path
>> modified/deleted/added in a commit is a whole separate request. For
>> 'adds', the client is likely doing an existence check: does the path
>> already exist? If so, fail the commit (the client is out of date).
>> Most of the time the answer is "404", i.e. "no, it doesn't exist, so
>> go ahead and PUT the file".) If this existence check didn't happen,
>> then there's a risk of the PUT simply overwriting an existing object.
>>
>
> I don't quite get that ... if what you say is true, then:
>
> * you don't gain anything by checking for existence with a GET
> before a PUT, since that just slightly narrows the race window for
> someone else creating the resource.
Correct. It catches out-of-dateness 'most' of the time, but not if
somebody slips in a commit just instant before your own commit
finalizes. Commit-finalization catches that rare situation. (And by
the way, it's a PROPFIND, not a GET, because the response is tiny. We
don't want to be existence-checking by accidentally downloading huge
files.)
> * In the context of Subversion doing a commit, every PUT that
> happens is the result of an editor drive callback, which implies
> that we *do* already know which objects are on the server.
Incorrect. mod_dav_svn always begins a txn as a copy of "HEAD at that
moment". That HEAD may be newer than what the working copy is sending
an editor drive against. So these checks allow us to fail out early
due to out-of-dateness.
>
> It's quite possible that we had such checks in there becasue we wanted
> compatibility with non-Subversion DeltaV servers or something. Even in
> that case, the PUT could be conditional -- just adding an
> If-Unmodified-Since header should safely avoid any PUT races.
Ooh, interesting. Gstein could comment on whether this is feasible...
On Thu, Oct 29, 2009 at 4:29 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> It'd be just as bad to send all the data and have the commit rejected
> (properly) because it is out of date. That said, couldn't we add a
> custom REPORT request or something where we send all these checks to
> the server in one batch before we start the PUT phase?
That might help, possibly. The final result, I hope is that we end up
doing what DVCS systems do: after this initial REPORT sanity-check,
push the entire CL in a single PUT, not divide the CL into a zillion
tiny write requests.
> I know the
> HTTP v2 stuff eliminated the PROPFIND, did it do anything like this
> too? Would it be worth looking at if Kevin wanted to?
PROPFIND wasn't eliminated; just spurious *uses* of PROPFIND which
mindlessly followed DeltaV formalisms. PROPFIND still has simple
legitimate uses (like... fetching props!). :-)
> I still prefer HTTP for all of the things that Apache gives us. Now
> that we are willing to "improve upon" WebDAV why shouldn't we consider
> other opportunities to speed up our usage of HTTP?
Preaching to the choir!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412886
Received on 2009-10-30 03:15:27 CET