Re: update processing

Ben Collins-Sussman wrote:

> The only appeal of this model was it's symmetric niftiness, I suppose.
> That, and the fact that there would be a lot of shared code on the
> filesystem side. In the current situation, libsvn_ra_local needs to
> learn to drive the filesystem API for it's own specific needs -- it
> probably can't just duplicate code out of libsvn_ra_dav. And I'm
> guessing the filesystem API is a bit hairier than the editor API.

Libsvn_ra_dav doesn't touch the filesystem API at all; it's on the wrong
side of the network connection, with mod_dav_svn on the other side.

Libsvn_ra_local and mod_dav_svn should share the bits for accessing the
filesystem. Maybe mod_dav_svn could live on top of libsvn_ra_local once
it's implemented, and ra_local would become the "real" public filesystem
API. Whether that makes sense for mod_dav_svn, I have no idea; GregS can
answer that one, no doubt.

> But practicality is important, too. It's no big deal. :)

Decoupling mod_dav_svn from libsvn_fs would be practical, too. :-)

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/