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

Re: solution to issue 704

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-05-19 19:43:57 CEST

Ben Collins-Sussman <sussman@collab.net> 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...
> </S:replace-directory>
> <S:resource-walk>
> ...lots of opened files and dirs, *nothing* but vsn-rsc-url props...
> </S:resource-walk>
> </S:update-report>

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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 19 19:47:02 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.