[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to get started

From: Mark E. Hamilton
Subject: Re: How to get started
Date: Thu, 19 May 2005 13:04:29 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913


Todd has some excellent suggestions, most notably his first: 'THROW NOTHING AWAY'. Sounds like something that should be printed in very large type and posted on everyone's wall.

I'd approach it in a slightly different way, however.

1. First create your repository.

For the following steps, ensure that no one is working on the code in the production area.

2. Next, import everything from the current production area into the new repository. This puts everything under revision control, saving all the historical information. It also ensures you have a complete, current backup if anything goes wrong in the next steps. Sure, it may be a lot of irrelevant stuff, but disk space is cheap.

3. Rename the current production area to some backup name, and make it read-only as Todd suggests.

4. Check out a new version of the production area from your repository. Everything should be the same as it was before you moved the previous one, but now it's all version controlled.

(At this point developers could start working again, though as everyone has said working in the production area is a bad practice.)

5. Now you can start the remove/test cycle that Todd suggests, with the assistance of a Senior Developer. Do all the removes using scripts, with each file named individually in the script. That way, if the results of a remove script need to be undone it's a simple matter to change all the 'cvs remove' commands to 'cvs add' and run it again. (Perhaps one of the real gurus here knows a simpler way to do a wholesale add of all removed files without having to specify the names, but I don't.)

With as many files as you have you probably want to do your removes in large, clearly related chunks (ie, all files matching *.bck or *.bak first, then ones with dates, etc.) After each remove (or group of related removes) if everything still works, commit everything. When you remove something and it stops working, undo the remove, identify the specific file(s) that caused the breakage, then remove the others in that set.

Eventually you'll have things whittled down to the bare minimum of files that allow the system to work, but you'll still have all the historical information. And, if something turns out to have been removed that wasn't tested and is necessary, you can get it back from the repository at any time.

6. As Jim said, train your users in CVS. The sooner they can stop working in the production area the better.

However, it may not be possible to get management (or even developer) buy-in to a policy that forbids direct modification of the production area. In a situation like this it wouldn't surprise me to find that many of the scripts contain absolute references to other files in this production area, which would mean that they won't work in a developer's sandbox. The only solution to this is a (possibly) painful redesign process that makes all absoulte references into references relative to the root of the product hierarchy. This is a much better way to do it, but adding it after the fact can be tough.

Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]