Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > Huh? Doesn't the FS provide an editor for committing transactions?
> > And doesn't the FS drive an editor for updating a working copy? I
> > thought this was a basic part of the design.
>
> The FS interface is less restrictive. It provides functions which
> make it very easy to write editors, but don't actually require a
> depth-first traversal.
OK: so let me see if I understand.
* The filesystem currently has nothing whatsoever to do with editors;
it neither provides one nor drives one.
* libsvn_ra_dav *both* provides and drives an editor when talking to
libsvn_client, but with the filesystem it speaks directly.
* libsvn_ra_local, when it's eventually written, will similarly need
to both provide and drive an editor on the client side, and speak
the filesystem API directly.
I guess this makes sense, but it kind of blows a hole in the
idealistic vision we had that the "client and server can be directly
linked together." Once upon a time, we assumed that this was the
case; that each half could just magically "connect" using editors, and
that there'd be no way to detect that the network layer was in the
middle, because it too was using editors on both ends.
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.
But practicality is important, too. It's no big deal. :)
Received on Sat Oct 21 14:36:17 2006