[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-20 18:36:20 CEST

Beating a dead horse, regarding issue #704 ('switch' rewriting

I've hit a wrench in the solution I'm implementing, and really, it
seems to speak against the solution gstein suggested as well.

The current solution I'm using (which is almost like gstein's solution):

  - 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.

  - on the client side, we've expanded the parser's knowledge of the
    two new xml elements. when it sees a <resource>, it simply calls
    the set_wc_prop callback on the full path.

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
wc. Only the update-editor has been properly "pre-anchored" in the
working copy, and thus the only safe way to set wcprops is through
this editor. (...unless we want to pass new arguments into
RA->do_switch() that indicate where the update-editor is anchored,

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, full of replace_* calls. (I mean, it could look completely
different, but what's the point? Why write a new parser to drive the
same editor?)

Following the logic through: if the resource-walk tree must look like
an editor drive, then it makes sense for mod_dav_svn to re-use its
xml-editor, and make 'adds' look like 'replaces' (passing
SVN_INVALID_REVNUM for the base-revision args.)

Back to square 1 again. Essentially what Karl suggested: tweak the
editor docstring promise, so that the base-revision sanity check is
optional. Grrrrrr.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 20 18:39:35 2002

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.