On Mon, May 20, 2002 at 11:36:20AM -0500, Ben Collins-Sussman wrote:
>...
> - on the server side, we get a free fs 'walk' from dir_delta by
> comparing the switched tree against revision 0. dir_delta is
> driving the xml-output editor in a secondary <resource-walk> mode,
> which produces a *flat* list of <resource> elements that contain
> just full paths and vsn-rsc-urls.
The flat list seems fine. I dislike using dir_delta as a mechanism to do a
walk, though. It smacks too much of "everything is a nail for dir_delta to
smack."
>...
> PROBLEM: It's useless to send back a flat list of absolute fs-paths
> and vsn-rsc-urls, because we don't know *where* to apply them in the
Ben and I talked about this, and I'm copying the result here.
The problem is sending back absolute FS paths, rather than relative to where
the switch report was based. If the server simply sends back a relative
path, then the client can pass that along to set_wc_prop().
[ at the moment, the client doesn't need any additional prefixes; the base
of the report is always the same as the session root URL; the path to
set_wc_prop is relative to that point, so everything is aligned. In some
future situation, where we may have one root and multiple sub-reports,
then the returning paths would be relative to the sub-report and a prefix
would be needed... just not today. ]
>...
> So if ra_dav is going to have to re-drive the update-editor to set
> wcprops, then the resource-walk tree should *look* like an editor
> drive,
But it won't have to drive the update editor, since you've got correct paths
for set_wc_prop, so everything is happy-happy.
>...
> Back to square 1 again. Essentially what Karl suggested: tweak the
> editor docstring promise, so that the base-revision sanity check is
> optional. Grrrrrr.
Nope nope... much simpler. Just tweak the return paths.
The base-revision should remain a strong condition (and/or docs clarified)
regardless of this change, but editor drives are overkill here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 20 21:54:11 2002