da plan

[Karl Fogel <kf...@galois.collab.net>]

Earlier, I said that we should concentrate on hooking networking up
with the repository, because having a networked svn is our first goal,
and that providing local repos access was a secondary consideration.

However, this would mean doing two new things simultaneously: making
the filesystem api work, and making networking work.

Without changing the goal for m2 (connecting to the repos over the
wire), I'd like to change how we go about it.  Debugging the
filesystem code over the wire would be very difficult.  And fixing any
"theoretical" problems regarding wc<-->repos communication is only
confused by throwing the network layer in the middle -- it makes it
difficult to distinguish genuine wc<-->repos problems from
wc<-->networklayer and networklayer<-->repos problems.

So I think working in these stages would be better:

   1. Make fs api work independently, as much as possible, testing
      with its own tests.

   2. Make client work against fs api, via a simple ra_local layer.
      This shouldn't be too hard to write, just a shallow
      svn_delta_edit_fns_t wrapper around the fs api.

   3. Stick the network in the middle.

Greg, this shouldn't bottleneck you any more than you're currently
bottlenecked.  The point is to get the fs solidified as fast as
possible, then make sure that the theoretical model works in practice
(via ra_local), _then_ put networking in the middle.

What this means is that I'll be spending my time mostly on 1 and 2
with JimB and Branko for the next couple of weeks (but they're gone
for the holidays, so I have some time to really mess up the filesystem
code, heh!).  Then we'll have a solid foundation for step 3.

How does this sound?

-K

Re: da plan

[Karl Fogel <kf...@galois.collab.net>]

Greg Stein <gs...@lyra.org> writes:
> > The point is to get the fs solidified as fast as
> > possible, then make sure that the theoretical model works in practice
> > (via ra_local), _then_ put networking in the middle.
> 
> Well, I'd be continuing to use the network in the middle. So we don't want
> to break the use of ra_dav.

Oh, definitely.  No fs functionality will be written in such a way
that it works for local but somehow not for network case.

> It should also help with the RA API and with ripping out some of the XML
> specific stuff from the cmdline (as I've suggested, there may be room for an
> ra_xml to interact with XML files).

Ezzactly, yeah.

-K

Re: da plan

[Greg Stein <gs...@lyra.org>]

On Tue, Dec 26, 2000 at 10:43:29AM -0600, Karl Fogel wrote:
>...
> Without changing the goal for m2 (connecting to the repos over the
> wire), I'd like to change how we go about it.  Debugging the
>...
> So I think working in these stages would be better:
> 
>    1. Make fs api work independently, as much as possible, testing
>       with its own tests.
> 
>    2. Make client work against fs api, via a simple ra_local layer.
>       This shouldn't be too hard to write, just a shallow
>       svn_delta_edit_fns_t wrapper around the fs api.
> 
>    3. Stick the network in the middle.
> 
> Greg, this shouldn't bottleneck you any more than you're currently
> bottlenecked.

Not at all. It is quite independent. Given the network in the middle, I can
actually work on the two sides independently. "is the client sending the
right stuff?" or "if I feed the server <this>, does it respond properly?"
Through incremental work, I can then start "really" hooking the two sides
together.

> The point is to get the fs solidified as fast as
> possible, then make sure that the theoretical model works in practice
> (via ra_local), _then_ put networking in the middle.

Well, I'd be continuing to use the network in the middle. So we don't want
to break the use of ra_dav.

>...
> How does this sound?

Fine here. "No big whoop"

It should also help with the RA API and with ripping out some of the XML
specific stuff from the cmdline (as I've suggested, there may be room for an
ra_xml to interact with XML files).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/