[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 13:01:03 +0200

> -----Original Message-----
> From: rhuijben_at_apache.org [mailto:rhuijben_at_apache.org]
> Sent: vrijdag 17 juni 2011 12:29
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1136838 -
> /subversion/trunk/subversion/libsvn_client/commit_util.c
> Author: rhuijben
> Date: Fri Jun 17 10:28:33 2011
> New Revision: 1136838
> URL: http://svn.apache.org/viewvc?rev=1136838&view=rev
> Log:
> * subversion/libsvn_client/commit_util.c
> (svn_client__do_commit): Following up on r1136429, r1136530 and
> r1136823,
> use a more informative error report for the most common ra_serf out of
> date
> error.
> The other RA layers report out of date earlier, but ra_serf (and probably
> neon) commonly reports out of date from here.
> An improved fix might be to fix serf/neon as this indicates that some files
> that aren't out of date may already be transfered.

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.

Received on 2011-06-17 13:01:40 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.