florin@iucha.net (Florin Iucha) writes:
> > I believe that the tight coupling between web server and
> > repository is a HUGE negative, one that will allow CVS to retain
> > the upperhand for many (if not most) of those currently hosting a
> > CVS repository.
>
> It is a huge positive since they got somebody else to test and debug 60%
> (I am making this number up) of the code required to support client
> server operation.
That was the basic idea -- reuse wheels. How else could we possibly
go from zero to self-hosting just over one year?
Writing a server and a protocol is NOT a trivial thing. Just look at
the cvs binary running in 'server' mode: it's not very stable, and the
protocol is crappy. And that's the product of a lot of work by Cygnus
and Cyclic corporations... (no offense to them! We just didn't want
to get bogged down in the same task.)
And now we have interoperability, too: you can 'mount' an svn
repository on Win32, OS X, and Linux.
> > I get a kick out of this comment from the documentation:
> >
> > > Feel like writing a new network protocol for Subversion? Just
> > > write a new library that implements the RA API!
> >
> > LOL! That's quite a big JUST.
Heh, sorry, that was my quote. :-)
Yes, it's a big hurdle. svn_ra.h is a wide API, but I think it's
still a great thing that the network layer is abstracted in the first
place. Just try to imagine making CVS work over some new protocol --
all of CVS's network functionality is 'stapled on'. At least we've
got a modular design from the start, which is a big help.
And I don't know why nobody's mentioned this yet -- there *is* work
happening (slowly) on an ra_pipe implementation. M.B. King and others
have spent time on marshalling the ra API over xml... in theory,
someday we'll have this pipe happening over ssh. mbk can comment more
on this.
(Personally, I think it would be nice to use xmlrpc for ra_pipe;
there are libraries out there that make it absolutely trivial to write
xmlrpc client and server programs.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 30 01:18:26 2002