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

RE: svn commit: r1136838 - /subversion/trunk/subversion/libsvn_client/commit_util.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 17 Jun 2011 16:34:23 +0200

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: vrijdag 17 juni 2011 16:27
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1136838 -
> /subversion/trunk/subversion/libsvn_client/commit_util.c
>
> On 06/17/2011 07:01 AM, Bert Huijben wrote:
> > I think this is a HTTPv2 limitation: In HTTPv1 we used to perform a
> > checkout on open_directory() where we (somehow) passed the
> base_revision
> > and got an out-of-date report.
> >
> > With HTTPv2 we only pass the base revision to proppatch, so the out of
> > date check for files only works on the MD5 hash we sent for the update.
> > (So theoretically we might see issues on MD5 collisions)
> >
> > I think we should at least verify the base_revision somewhere in the PUT
> > code path.
>
> We are including the base revision in the PUT request, right? (See
> libsvn_ra_serf/commit.c:setup_put_headers(), for example.) Are you saying
> that mod_dav_svn isn't verifying it?

Ok, I found the code where we do verify the base revision. (Thanks for the pointer)

But only verifying it in the PUT requests, voids the optimization in our libsvn_client commit processing where we delay the puts until we completed all restructuring operations.

In theory the commit can now fail with the last PUT request (after much data has already been transferred), while on the other RA layers not a single file would be transferred before we find out that some node is out of date.

        Bert
Received on 2011-06-17 16:34:57 CEST

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.