da plan

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
Received on Sat Oct 21 14:36:18 2006