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) Bert Huijben (Cell phone) From: Ivan Zhakov Sent: donderdag 7 juli 2011 18:45 To: C. Michael Pilato Cc: [email protected] Subject: Re: svn commit: r1143860 - /subversion/trunk/subversion/libsvn_ra_serf/update.c On Thu, Jul 7, 2011 at 19:17, C. Michael Pilato <[email protected]> wrote: > On 07/07/2011 10:55 AM, [email protected] 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). -- Ivan Zhakov
