On Sunday, October 13, 2002, at 05:22 PM, Branko Èibej wrote:
> David Mankin wrote:
>
>>
>> On Sunday, October 13, 2002, at 02:57 PM, Stephan Feder wrote:
>>
>>> Has anyone thought about implementing a CVS server that uses
>>> subversion
>>> as backend?
>>>
>>> Regards,
>>> Stephan
>>
>>
>> That's a pretty neat idea. I had earlier suggested the idea of an
>> subversion client(-wrapper?) that understood the CVS command line
>> flag structure. Then it would be possible that IDEs and other
>> programs that already "integrate" with CVS through the CLI would be
>> able to, de facto, talk to SVN.
>>
>> If such a thing existed, then maybe you could use that for ssh access
>> instead of ra_pipe. A CVS client could be configured to use rsh/ssh
>> access to the CVS-friendly SVN client. That could provide the same
>> results as a CVS sever that uses subversion as a backend.
>
>
> *sigh*
>
> Every one of these ideas has been discussed before.
Thanks for the analysis, Brane. But I think you're conflating ideas 2
and 3.
> 1. SVN client can connect to CVS server. This requires creating a new
> RA layer, call it ra_cvs. It also has a ton of problems:
> * How do you simulate the global repository revision?
> * How do you map CVS tags and branches into the SVN namespace
> * What to do about unimplementable features -- moves, renames,
> atomic commits, etc?
> 2. CVS-like client can connect to a SVN server. To achieve this, you
> have to either extend CVS client (eeek, have you looked at the
> code?), or write a new server that understands the CVS network
> protocol and speaks to the Subversion repository. This is doable
> (e.g., by using the Python bindings), but again has some problems
> -- in fact, theyre the complement of the problems in (1).
Your answer #2 seems rather to address:
2. CVS-server can talk CVS network protocol.
Would you also please address:
3. CVS-like client can connect to a SVN server. (I.e. a client
which implements the CVS commandline syntax (and MAYBE WC semantics).)
Maybe #3 should be split into 3a: with CVS WC semantics, and 3b: with
SVN WC semantics.
> To summarize: yes, it can be done, and it'd be way cool, but it's a
> huge amount of work. I've always thought it would make much more sense
> to put the effort in a) making cvs2svn really work (e.g.., teach it to
> understand tags and branches), and b) get some more Subversion clients
> working (Emacs vs-mode integration, a pcl-cvs-like interface, a really
> good GUI client, and perhaps integration with IDEs). Do that, and
> migration will be much easier.
a) Alas, I don't know python and don't have any time to learn.
b) It'd be swell indeed if every IDE/editor/GUI client that can talk
CVS today could talk SVN in the future. However, there are lots of
them which is why I proposed making SVN CVS-compatible as a
kill-many-birds-with-one-stone approach. (Or at least injure many
birds with one stone so they don't get away while you kill them one at
a time. (Yuck, this metaphor just got too icky to keep using. Sorry.))
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 14 06:35:42 2002