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