How to get started

[Rondal Ellifritt]

I have recently been hired into an existing development group. One of my
tasks is to get the group using version control. The decision has
already been made to use CVS. This is fine with me, but my only
knowledge of CVS is from the reading I've done over the past couple of
weeks and some experimentation I've done in a scratch directory
structure. So I'm looking for some advice on how to get started.

The group has a large existing code base. This code base is almost all
unix shell scripts and perl code (plus the usual attendant config files
and a few semi-static data files) which get edited and executed in
place. That is, there is one directory where all work gets done, and
that's also the production execution directory. (I know this is bad
practice. But it will take time to change people's work habits, whereas
I'm hoping to get version control set up pretty quickly.)

Since this has been going on for years, and since developers have been
smart enough to institute their own sort of "manual" version control,
there are a lot of old, datestamped, backup files that represent
previous versions of current files. (And, of course, variations on this,
such as files stamped with developers' initials, or marked '.bak' or, my
personal favorite, '.new'.) The real problem is that, in a directory of
nearly 2000 files, probably fewer than 100 deserve to be versioned
(i.e., are currently in use). I realize standard practice would be to
clean up this directory before I import it, but there are two things
that make that impractical. First, since I'm new to the group, I don't
know for certain which files deserve to be versioned. Second, as I said
above, this is the production run directory. Removing a file that is
still in use could break the production system.

I have two major goals:

   1) Get the current version of the source code under version control.
   2) Don't immediately force anyone to drastically change their work
habits. (Remember, I'm the new guy, the low man on the totem pole. If I
try to make everyone else conform to my ideal development environment,
they'll ignore me and continue with their evil ways. I'm trying to
slowly nudge them toward the path of righteousness.)

I also have two minor goals:

   3) Don't place under version control huge numbers of files that
shouldn't be there.
   4) Preserve history where possible.

I'm willing to compromise 3 & 4 for the sake of 1 & 2, but I'd prefer to
find a scheme that doesn't require me to do so. Here's what I'm thinking
so far.

1. Copy (cp -pr) the production run directory to a temp directory.
2. Clean up the temp directory as best I can, deleting things I'm not
sure about (that is, erring on the side of reducing the number of files
to be imported).
3. Import the temp directory as the production project (cvs import -m
"Initial Load" <project> <project> initial).
4. Delete (rm -rf <project>) the temp directory.
5. Recreate the temp directory out of cvs (cvs co <project>).
6. Copy (cp -pr) the resulting CVS directories from the temp area to the
production run directory.
7. Tell developers that their workflow has changed as follows:
   A. Edit file(s) in place as they always have.
   B. When finished, check in their changes (cvs update <file1> <file2>
... <fileN>).
   C. If cvs responds that any given file is unknown, add the file to
the repository and then check in their changes (cvs add <unknownFileK> ;
cvs update <file1> <file2> ... <fileN>).

I think this will achieve goals 1, 2, and 3, but it will do nothing
toward 4. (But if that's the best I can do, that's still not too bad.)

If anyone has any suggestions or advice, or spots any obvious (or
subtle) pitfalls in my plan, I would greatly appreciate a shout out.

Details: I'm using cvs 1.11.17 (dictated by corporate).

Thanks for listening,
Rondal