[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 |
Rondal,
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.
505-844-7666