> -----Original Message-----
> From: Bert Huijben [mailto:bert_at_qqmail.nl]
> Sent: donderdag 7 juli 2011 18:57
> To: Ivan Zhakov; C. Michael Pilato
> Cc: dev_at_subversion.apache.org
> Subject: RE: svn commit: r1143860 -
> /subversion/trunk/subversion/libsvn_ra_serf/update.c
<snip> moved first part of the mail below
> Bert Huijben (Cell phone) From: Ivan Zhakov
> Sent: donderdag 7 juli 2011 18:45
> To: C. Michael Pilato
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1143860
> - /subversion/trunk/subversion/libsvn_ra_serf/update.c
> On Thu, Jul 7, 2011 at 19:17, C. Michael Pilato <cmpilato_at_collab.net>
wrote:
> > On 07/07/2011 10:55 AM, ivan_at_apache.org wrote:
> >> Author: ivan
> >> Date: Thu Jul 7 14:55:19 2011
> >> New Revision: 1143860
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1143860&view=rev
> >> Log:
> >> Fix calculation X-SVN-VR-Base request header in ra_serf.
> >>
> >> This commit reverts r1142065 and r1143089.
> >>
> >> * subversion/libsvn_ra_serf/update.c
> >> (report_dir_t): Remove repos_relpath.
> >> (report_context_t): Remove root_is_switched.
> >> (start_report): Do not update repos_relpath.
> >> (end_report): Use only wcprops as source for delta base. Our current
> >> protocol doesn't gives us stable way to construct delta base without
> >> wcprops. We can optimize it later.
> >
> > Whoa! wcprops again? Can you explain this? wcprops only ever existed
> > because it was too expensive to ask the server to give us a URL to
describe
> > a particular object. But URL generation is *supposed* to be trivial in
> > HTTPv2, so... what's up?!
> >
> We cannot calculate them even over HTTPv2 in case of switched paths
> (or file externals). Bert implemented some heuristic in r1142065, but
> as any heuristic method. Really stable way to fix the problem is to
> include property with repos relative path to update report.
>
> The problem that old code actually didn't work: X-SVN-VR-Base request
> header was simply ignored by server (see r1141845).
[ from the top of this mail]
>
> This was no heuristic. This was always guaranteed the right
> information, because it was obtained from the wc just after obtaining
> the write lock.
>
> If this would be some heuristic ANY UPDATE would be some heuristic as
> the update itself is driven based on the same information. (Except that
> it is stored in a tempfile on the server because storing a revision,
> lock, path, etc for every node can easily be to big to store in ram.
> The number of switches in a wc is- just like the obtained locks-
> typically very low)
>
Any update is started by reporting the revisions and paths in the working
copy to the repository via a svn_ra_reporter3_t instance.
From the information in this report the server sends the minimal list of
changes necessary to change the working copy into the state of the target
revision.
My patch extracted the paths that are switched against their parent from
this information and store these in a hashtable to generate the stable urls
we need here.
Why did you disable/remove this code?
We now fall back to using the dav cache code which we explicitly said that
we no longer need for HTTPv2.
This disabling adds one wc-db query for every file updated (measurable
performance penalty) and makes non-wc updates (e.g. svn diff URL1 URL2) use
full texts where it could use binary diffs before.
Bert
Received on 2011-07-12 00:46:45 CEST