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.
* 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. Since
the whole commit is a transaction at the repository layer, any PUT
that would overwrite an object that's "already there" would in
fact fail due to a conflict at txn commit time.
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.
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2412826
Received on 2009-10-29 22:31:13 CET