Bob Miller <kbob@jogger-egg.com> writes:
> cvs2svn will be a Unix command line tool. No GUI. No HTTP interface.
> No bonoboification. Not an emacs macro.
ROTFL.
> All CVS repository operations will be done through the cvs
> command, if possible.
+1
> main in Perl. cvs log parsing and commit aggregating in Perl.
> Subversion access in C through the svn_delta_edit_fns_t switch.
>
> OR... write the whole thing in Perl, and call both the cvs
> client and the svn client through fork/exec or popen.
Either way, it's good that you're going to use the existing perl code;
it's very solid at this point.
I suspect the 2nd method above might be easier, but much
slower... what with the overhead of launching a new process for *each*
svn commit.
> We could use XS or swig to call C from Perl. At some point, a
> Perl zealot may want to add that so he can write a perl
> subversion client. I am not that Perl zealot.
Heh. In theory, once libsvn_client is finished, it can be the basis
for the command-line client, GUI client, or whatever. I bet someone
will write a Perl module for this library in 5 minutes... and I bet
Greg Stein will write a Python module in 3. :-)
> It seems like it would be easy to use cvs and svn.
> The whole program would be (in pseudocode):
>
> commits = read_cvs_logs_and_figure_out_what_to_do();
> for commits {
> cvs checkout ...
> svn commit ...
> }
>
> ...
>
> The svn client isn't written yet. That's a problem.
>
Indeed, the libsvn_client library probably won't be written until most
of the routines in libsvn_ra_dav and libsvn_wc are functional. If you
go through the work of writing C code to
* grab an svn_delta_edit_fns_t out of libsvn_fs
* invoke the working copy "crawler" with this vtable
...then you've essentially implemented what will someday be known as
svn_client_commit() ! The only difference is that the real
svn_client_commit() will grab its vtable from libsvn_ra_dav instead.
> Since CVS doesn't support renaming files directly, I expect to
> need some ad-hocu-ery to recognize renames.
I'm not sure this is a worthwhile goal. CVS doesn't support renames,
and I tremble at the kind of deduction loops you might need to go
through to make these guesses; your tool would no longer be a "cvs2svn
repository converter" but instead a "cvs2svn repository
*improver*". :-)
As nice as that sounds, I don't think it's worth the effort. In CVS,
renames look like "deletes and adds". If the CVS repos users were
willing to live with the fact that rename-history is lost, they'll
certainly be willing to live with it in the svn repository (with a
bright outlook on future renames, of course.) Similarly, if the CVS
repos users *weren't* willing to live with that fact, they probably
already hacked the repository to preserve history, and therefore
aren't expecting any new miracles from your tool.
Received on Sat Oct 21 14:36:08 2006