Ben Collins-Sussman wrote:
This idea just isn't possible. CVS and SVN are just so
> fundamentally different under the hood (despite UI similarities),
> there is *no* way a subversion server can ever "translate" cvs
> protocol into subversion semantics. That's my feeling.
It's probably do-able... yes, they're different, and the translation
would probably have to have a caching element (for example CVS tends to
send whole files rather than deltas from the client), but the CVS client
is actually rather a dumb beast, and the obvious differences like
version numbers can be faked anyway (just stick '1.' in the front is
probably enough... there's little or no parsing of it anyway.. something
a bit smarter would be nice but I'd have to look closely at it so see
whether it's worth it).
Client->Server CVS just sends a bunch of arguments and the command,
followed (optionally) by the files and/or entry daya... then you just
have to work out the equivalent SV command and pass that onto the SV
server. Server->Client is even simpler... the CVS client just does what
it's told by the server - it doesn't actually implement anything itself
(this is why for example with all the changes I made to CVS I can only
think of a couple of cases where the client had to change).
It doesn't have to be perfect, just enough to work with the existing
CVS-aware tools (at least those that don't try to parse the response
text... I doubt there's a way it would ever work with Eclipse, for
example).
Tony
Received on Wed Aug 27 15:43:36 2003