solution to issue 704

Just wanted to present the latest solution gstein and I came up with
regarding issue 704.

The bug is that when you 'switch' part of a working copy to a new URL
(which is just a fancy type of update), most of the cached
vsn-rsc-urls are no longer valid. The items that were patched get new
wcprop values; but items that merely have their working revs and
URL's 'tweaked' still have secret vsn-rsc-urls that are left pointing
to old locations. That's the reason why cmpilato accidentally
committed changes to /trunk from his switched libsvn_fs working copy.

It's not enough to just erase all wcprops when doing post-update
revision bumping; that implies that libsvn_wc understands what the
wcprops are doing. It shouldn't be that aware; the wcprops should be
*strictly* managed by the RA layer that created them. libsvn_wc just
blindly stores and retrieves them on demand of RA.

So the proposed solution is to extend our update-report-response a
bit. Right now, it looks like this, just an XML version of an editor
drive:

<S:update-report xmlns:S="svn:" xmlns:D="DAV:">
<S:target-revision rev="1971"/>
<S:replace-directory rev="1965">

...lots of opened files and dirs, props, and 'fetch-file' commands...

</S:replace-directory>
</S:update-report>

The new format would allow a new 2nd tree-walk to be embedded at the
end of the first walk:

<S:update-report xmlns:S="svn:" xmlns:D="DAV:">
<S:target-revision rev="1971"/>
<S:replace-directory rev="1965">

...lots of opened files and dirs, props, and 'fetch-file' commands...

</S:replace-directory>

<S:resource-walk>

...lots of opened files and dirs, *nothing* but vsn-rsc-url props...

</S:resource-walk>
</S:update-report>

The second "walk" would actually describe the vsn-rsc-url for *every*
resource below the anchor directory, rather than just those resources
that need updating.

Obviously, the 2nd tree-walk would only happen during an 'svn switch',
not a normal update.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 16 22:12:30 2002