Tony Hoyle <tmh@nodomain.org> writes:
> 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).
The fact that you said that ("just stick 1. in front of the version
numbers") tells me how much pain you're about to experience. It's
clear that you don't know much about Subversion yet. :-)
Let me warn you: this is not a problem of translating syntaxes,
it's a problem of translating semantics. For example:
* for an update, the svn server expects the working copy to report
version information about *directories*, not just files. one
system versions trees, the other just versions files.
* how about branches and tags? one system treats them as labels on
file-versions, and another treats them as whole directories.
The list goes on and on. Go ahead and try it. I'll keep my mouth
shut.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 16 23:08:37 2003