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 _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
