> Not quite. It is also very easy to have a "little" directory under
> svn/ which contains Apache. It can be preconfigured and set up
> specifically for SVN. As far as users are concerned, the fact that
> Apache is used could be completely invisible.
What bothers me about this is that, if they want to do something at
all different from what we've anticipated, they need to learn how to
configure Apache. From what I remember, Apache isn't too bad, but
seems like way more than necessary for the task at hand.
When we really sit down and work on making installation stone-simple,
we'll find out whether this was a good idea. I'm skeptical, but ready
to be sold.
Regarding ra_local, I think Greg's identified the real challenge here:
locking between Apache and a local access method. You need some way
to reliably clean up locks when someone crashes, which pretty much
means using another process somehow. We've delegated this to the
Apache main process, but we have no solution at present for the
non-Apache case.
We can cross this bridge when we come to it, though.
I think a lot of CVS's remote / local troubles stem from the way
remote CVS was implemented --- more of a forcible separation than a
comprehensible design. I think that:
a) simply having a common ra interface
b) keeping the stuff we do across that interface simple
will avoid most of CVS's problems.
Received on Sat Oct 21 14:36:10 2006