Ben Collins-Sussman <firstname.lastname@example.org> writes:
> 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...
> ...lots of opened files and dirs, *nothing* but vsn-rsc-url props...
There's a theoretical problem I'm running into, and I think it's going
to be a little weirder than I expected.
To generate this post-switch <resource-walk>, we're running dir_delta,
comparing revision 0 against the new switched-subtree. So dir_delta
is sending out an editor 'add' command for every single item in the
Now mod_dav_svn and ra_dav are responsible for marshalling this editor
drive over the network, to the *real* update-editor that's tweaking
the working copy. Obviously, the true update-editor doesn't want to
see any add_* calls -- it will get angry about obstructed updates. So
I've toyed with making either mod_dav_svn or ra_dav tweak the
marshalling so as to convert the add_* calls into open_* calls
instead. So the true update-editor just sees "open_*, set a wcprop,
close_*". Very simple.
Except that the open_* calls all require a 'base revision' argument,
which we don't have. This argument is supposed to be a sanity-check
for the editor -- to make sure that the driver and the editor both
agree on what's being changed. Now granted, our libsvn_wc
update-editor currently ignores the base-revision argument, but I just
can't bring myself to passing INVALID_REVNUM to every open_* call. I
mean, someday the update-editor may very well want to do sanity
checking. I don't want to violate the editor interface by driving it
It's a shame, because I've been able to essentially re-use both
mod_dav_svn's and ra_dav's editors to do the resource-walk, with
almost no modifications. It's been very nice. But now it seems that
I'm going to have to write a completely different parser in ra_dav for
the resource walk -- it won't drive the update-editor at *all*.
Instead, it will just call the 'set_wc_prop' callback sitting in the
RA session baton directly. Does that sound reasonable?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun May 19 19:47:02 2002