On Fri, Sep 22, 2000 at 09:24:10AM -0500, Karl Fogel wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > While poking around to try to answer your question, I found:
> >
> > http://www.loria.fr/~molli/cvs/doc/cvs_2.html#SEC11
> >
> > which describes how CVS stores data in the repository, and might be
> > useful as a paper documentation.
>
> Yeah. Also (at the risk of tooting my own horn), Bob you might try
> these links for some details of repository structure:
>
> http://cvsbook.red-bean.com/cvsbook.html#Repository%20Structure
I would recommend against trying to parse all the *,v files from CVS.
Instead I think using pure cvs commands to get/extract information and
pure svn commands to add/insert information would be better.
The clearcase model for converting stuff is a bit nasty looking at
first but does provide some nice capabilities after you look into
it a bit.
Basically the model is a two step process.
Step 1 - Create a conversion "script"
Step 2 - Process/Import the conversion "script"
The Step 1 creates a conversion "script" that can be used by a downstream
tool for importing new revisions. The process in step 2 is nice in that
it is independent of the tool you are moving from.
The conversion script actually uses native commands from the other tool
to extract versions. So for a file named foo with 4 versions 1.1->1.4
the script might be something like
file foo
version 1.1 extract command "cvs up -r %ver %file"
version 1.1 comment "Blah blah blah this is the original rev"
version 1.1 user cavanaug group rd permission 555
version 1.2 extract command "cvs up -r %ver %file"
version 1.2 comment ""
version 1.2 user cavanaug group rd permission 555
version 1.3 extract command "cvs up -r %ver %file"
version 1.3 comment "Fixing a stupid mistake by cavanaug"
version 1.3 user build group rd permission 555
version 1.4 extract command "cvs up -r %ver %file"
version 1.4 comment "Refixing it in a more maintainable manner"
version 1.4 user cavanaug group rd permission 555
The import script basically processes this and in the middle does something
like a svn add file with appropriate permissions, and svn commit file
with the correct checkin comment etc.
Generating the script can be a long long process and can create a long long
file to run on import. It also takes a long time to run the import but
typically you dont care about how long something takes during a conversion
just that it works.
This model is also nice in that it separates the process for writing an
export tool (Step 1) from the import tool (Step 2). The benefit is that
you dont need to be an expert at both the old tool and the new tool
in order to migrate a codebase.
PS. I might sign up to write the Clearcase->SVN translator. ;-)
--John Cavanaugh
Received on Sat Oct 21 14:36:08 2006