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

Re: Fixing issue 644

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-04-18 04:16:21 CEST

On Wed, Apr 17, 2002 at 11:34:50PM +0100, Philip Martin wrote:
>...
> There doesn't appear to be a way to detect the conflict on the server
> since in dav_svn_open_stream() in mod_dav_svn/repos.c there doesn't
> appear to be a way to distinguish updates from creates. Without
> wishing to spend hours reading WebDAV specs, am I missing something?

The code already detects the difference. It tries to apply a text delta, but
that could fail cuz the file isn't there. So it creates it, then applies a
text delta again.

I think the point is that you're saying that the protocol needs to be able
to say "don't overwrite". Correct?

> Assuming it is hard for the server to do this, I was thinking of
> getting the client to call svn_ra_dav__get_props_resource on the path
> to be added, and detecting the conflict by the fact that the function
> doesn't fail. Does this sound like the right solution?

No, I don't think so. That would imply a PROPFIND roundtrip for every PUT
operation. Ick.

I believe that we can use an If: header or an If-<something> header
associated with the PUT to say something along the lines of, "If nothing is
there" or "Only if revision FOO is there".

Normally, when we do a PUT, we send a diff with a base for the diff delta.
That could be half of the verification: that the target we're PUTting
against is actually what is described in the delta. Hmm. But that isn't
quite right. We might want to PUT a file to location FOO, but describe that
file as a delta against BAR.

Ah well. An If header seems the right approach. In HTTP / WebDAV terms, If
headers are assertions about the state of the resource specified by the
Request-URI. In our case, we want to assert the file is or is not present.

More thinking seems necessary...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 18 04:16:44 2002

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.