Re: Migrating from VSS to CVS

[Laine Stump]

Ephraim Ofir <address@hidden> writes:

> Any advice and tips would be greatly appreciated.

My first advice would be to look back through the info-cvs archives (I
forget where they are, but I believe the email you received when you
subscribed should point you at them) for "VSS" or "Source Safe".

Beyond that, there are a few scripts written by Jerry Nairn which I
enhanced a bit and put at:

    http://www.laine.org/cvs/vss2cvs

Roughly speaking, this is the *mechanics* of the actual conversion of
the repository using these tools:

1) On a Windows PC that has access to both the VSS and the CVS
   repository, install perl 5.6.0, cvs, and vss. Run vss2cvs.pl
   (possibly multiple times (for multiple projects and branches),
   figuring out the appropriate arguments). (Actually, I'd recommend
   initially doing the conversion to a CVSROOT on local disk, then
   moving that CVSROOT to the intended server - it's much faster that
   way).

2) On the CVS server, cd to the subdirectory of the cvsroot directory
   that contains the projects newly converted from VSS and do
   something like:

        find . -name \*,v -print | while read f; do massagecomments.pl "$f"; 
done

   This takes date+user info for the commits that was stored in
   comments by vss2cvs, and moves it into the "real" date+user fields.

For us, the difficult part is figuring out what to do with linked
files. VSS can link a single file in the repository to multiple places
in the work directories. CVS supports a similar functionality (via the
CVSROOT/modules file), but only for complete directories. We still
haven't decided on a final method of dealing with this (we'll probably
have to restructure our directories and makefiles in some way), but a
program that will help you in making an informed decision about this
is Jerry's "listshares.pl", which I've also enhanced a bit and put in
the same directory. In short, listshares.pl produces a list of
"directory sets", with each one followed by a list of all the files
that are shared in exactly that set of directories (for those of you
that previously used the program, if had produced a list that had a
separate entry for each file, rather than grouping all files with
identical shares together; the new format is *much* smaller and more
informative).

If anyone has any suggestions on what to do about files that are
linked in CVS (yes, we've already considered symlinks in the
repository, but that seems to be a bad idea for several reasons), I'd
love to heard them.

Once you've converted (btw, before doing that you'll want to get in
some practice using CVS, determine how to map your currect "daily
source control tasks" into CVS operations, and write up a short "cheat
sheet" tutorial for all your developers on how CVS can be simply used
in *your* environment. You may also want to look at the various GUIs
for CVS. My personal preference is TkCVS (you can find the latest
release, along with discussion, etc, by searching for "tkcvs" on
http://www.sourceforge.net), but some others prefer wincvs (maccvs,
gcvs), or some others. You'll find it takes some getting used to if
you're accustomed to the VSS GUI, and a few reporting capabilities are
missing (eg, a list of all commits between two particular dates), but
you'll also find some things that *aren't* in VSS (eg, a graphical
tree of all the different revisions and branches of a file, easy
merging of changes between branches, etc.)

Finally, read *everything* in the CVS manuals / FAQs / tutorials about
how evil file locking is, and how wonderful it is to *not* use it. CVS
does allow you to lock files for exclusive modification, but with very
few exceptions you *don't* want to do this. You'll probably find that
CVS' concurrent development model scares the hell out of some of your
VSS-accustomed developers, so make sure you know all the arguments on
both sides, so you can calm them down - once they get used to it, they
won't believe they could have ever lived with the locking model ;-)