Greg Stein <gstein@lyra.org> writes:
> Screw dir_delta. It isn't a "walk" system. It is about deltas. On the
> client, just map the incoming data to set_wc_prop. Clean and simple; and
> even better: understandable.
Hold on... instead of re-using editors on both sides of the network,
now you're telling me to re-use *neither*?
If mod_dav_svn doesn't attempt to re-use the xml-output-editor and
dir_delta, then fine: it can walk the fs manually. But now this
*guarantees* that I can produce a tree walk that is perfectly
re-usable by ra_dav's parser, and so ra_dav *can* simply re-drive the
update-editor with no hassle. (That's why the <resource-walk> in my
example was deliberately re-using the same xml elements as the
<update-report>!)
Conversely, if I allow dir_delta to send a tree full of 'add'
commands, I can write new parser code in ra_dav that avoids driving
the update-editor, and just calls the set_wc_prop callback.
Either of these solutions seems reasonable: there's no 'distortion' of
editor semantics going on, as long as one side or the other is
customized. It seems to me that the only 'distortion' is when we
attempt to marshal an editor drive on both ends. I don't understand
why you think *both* ends need custom code -- one end is enough, no?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 20 15:09:12 2002