Re: How to get started

[Todd Denniston]

Rondal Ellifritt wrote:
> 
> 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.

The first step here is realizing you throw NOTHING away. The second step is
figuring out how many different kinds of backup to make, before you begin
your cleaning.

If you are only going to put the latest working revs in CVS (see Maarten and
my discussion below on making this decision), the steps would be pretty much
as follows:
0) have a medium to senior _developer_ assigned to assist you, WHEN and AS
_YOU_ need answers/help.
Management hired you to do a job correctly, tell management you need
information that is only locked in the heads of its current experienced
developers to do the job correctly.  They will most likely get paid back
that developers time by the improved work process and quality after the
version control system is in place. And you might be able to convert one of
them by his/her learning with you.

1) have a senior developer come up with a test set that can be ran quickly
to determine if the system is still working.
2) `cp -rp` the working directory to a backup location and mark the
directory (and files) read only.
3) make a tar (or zip) of the working directory.
4) have the developer remove anything from the in use working directory,
i.e., the one they are currently using, that obviously is not being called
by the current working scripts.
5) quick test the system.
6) make a new tar and directory copy. (you have a working state, don't loose
it)
7) have the developer remove anything that looks like it is not being used.
8) fully test the system.
9) put it under CVS.
10) move the working directory out of the way (NOT DELETE), and do a
checkout from CVS in it's place.
11) start trying to get the developers to do their work in their own sand
boxes instead of the production area.

Maarten de Boer wrote:
> 
> Hello Rondal,
> 
> The situation sounds horrible. I cannot image how things have not gone
> completely ugly... 

Actually, if they have been following a procedure for naming the files for
their versions and keeping other records (out of band meta-data on which
versions work together), its not completely horrible. ... Just manual,
CVS/RCS/SCCS just make keeping that meta-data and version backups a lot
easier by automating it.  Certain government projects must still do it by
hand because the systems (hardware & OS) they are developing on make it
difficult, to impossible, to put a modern version control system on.

What is horrible is that they are keeping all the old versions in the same
directory with the working versions, making it near on imposible to figure
out what the current working version looks like.

> I understand your position, but CVS offers you
> several important features you will not be using with the setup you
> propose, and frankly, I really think that no one sane can dispute the
> advantages of a correct setup development environment over the mess it
> is now, or the slightly less mess it would be following your proposal.
> 
> The major problems I see with your half-way solution
> 
<SNIP>
> - It is an extremely bad idea to be working in the production environment,
> and using CVS inside it will not make it any better.

As soon as you get the whole code base under version control, it would be a
good idea to try and make the scripts install location independent, so that
each developer can have his/her own set to test with before making it live.
However, that will have to come immediately after getting the whole mess
under CVS and getting the current live directory setup as a checkout from
CVS, as the developers are still changing things and getting it install
location independent will take some time, this is where CVS can help you by
merging in the developer changes to the versions that are being fixed.

> 
> I really think that setting up CVS in such a half-hearted way will be
> dangerous. People will get a wrong idea of the use of CVS, and you will
> have even a harder time changing that idea, than changing their work
> habbits.
> 

I agree that if they get the wrong idea at the start, it will make
converting them MUCH more difficult. I think Maarten may be commenting on
the stance you take in step 7, as most of the people on the mailing list (I
may be way out of bounds here) believe work should be done in each users own
working area, and the production run directory should be controlled by the
CM person doing the appropriate `cvs update` commands.

Step 6 in your (Rondal's) procedure is the first mistake, 
you do not copy the CVS checkout to the production run directory, you simply
do it as the production run directory after having _moved_ the old one. 
and in Step 7 you should 
1) have them working in thier own directories.
2) always do `cvs commit` and `cvs update` with out passing file names, this
way ANY file changed gets taken care of, otherwise they could miss putting
changes into CVS that should have gone.


> I think it would make a lot more sense to do a gradual migration to CVS
> in a different way. Rather than doing CVS half-hearted on the whole
> codebase, you could take a small portion of the codebase, preferably a
> relatively young part, where all (or most) developers work on, and where
> a lot of changes are being made.
<SNIP>

While I agree with many of the things Maarten said, I disagree here.  I have
done a couple of these imports from ancient manual version controlled
projects. If you are going to do it at all, do the whole thing at once,
while you have the method of getting the old versions, into CVS, straight in
your head.  If I did not do the whole thing at one time, I usually gave up
on getting the old history in the repository and just went with the current
version of all the files I had not yet got in, so the developers could get
going on the whole thing. 

Not doing the whole base at one time IS half-hearted.

> 
> A last thing, I think you should forget about keeping the history,
> since, if I understand you correctly, their is no real structure or
> logic in the files-based history you have now.
> 
> Maarten

This is actually the biggest set of questions you need to ask yourself (and
possibly the management and coders).

Is having the old versions in the new version control system (VCS) (CVS in
this case) worth the trouble?

Would it be more cost effective (and at least as useful) to put the current
manual repository in an archive directory for reference, and just put the
current versions in the new tool?

If you must put the old versions in the new VCS, 
a) do all of them need to go in, i.e., can you skip ones that are developer
only revs?
b) where are the records indicating the versions or dates of files which
made up coherent sets?
c) which developer is going to set with you to identify the needed versions?
d) what are the names of the tags you want to use for the coherent sets?



Maarten de Boer in another message wrote:
> You could keep the version history, if files are datestamped more or less
> consistently... If I understand you correctly, a file foo could have copies
> over time, 
...
> I[t] should be rather easy to write a script that looks for all those
> versions of file foo, and commits them one by one, ordered by time,
> putting the version suffix in the log message. The main problem here is
> that you should put the oldest version in your initial import.
> 

If you are going to import all of the revs, I would suggest following
Maarten's suggestion of writing a script (or a dozen), but if you want to
have the dates it might be easier using RCS to build the ',v' files and then
move them into the CVS repository.

If you are going to use CVS import, I would actually suggest using your
scripts (or do it by hand) to try and build coherent sets in different
directory (structures) to import, and then import each set. It gets very
hard to keep track which set a particular file goes in if you do it one file
at  a time.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter