Re: Updating Old Repository

[Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code 6067]

Huber, Robert wrote:
> I have an out of date repository that I want to make current with the
> latest versions of code that are in production.  I'm thinking create a
> sandbox with all the code checked out and mark all the files for edit.
> Overlay the code from the official production environment then commit
> everything. What would happen to code that is new? 

"mark all the files for edit."???
have you used CVS before, or are you using watches?
Unless watches are being used to make things read only, you should only need 
to checkout. With watches I suppose you may need to issue cvs edit on all the 
files.

>  
>
> All of the version in the repository are currently 1.x, is there a way
> to create a version 2.1 for all of the code old or new and stat building
> from there.

wrong answer:
you can assign a revision [0].
find . -type f |grep -v CVS |xargs cvs commit -r 2.1
But you may want to read a story of woe about doing it[1]

right answer:
Ignore the cvs _revision_ information, it is for CVS's use only.  By changing 
the cvs revision information you may run the risk of breaking assumptions the 
cvs code has about things being on the 1.x revision set[2] and no those 
assumptions are not documented any where.
Use tags (symbolic names [3])for the humans, i.e. if you want the set of files 
in a sand box versioned for 2.1
cvs tag VERSION_2_1
there are some restrictions on the content of a tag name (second paragraph of 
"Tags–Symbolic revisions"[3])


[[ If any of our long time readers has significant changes that should be made 
to the above comments, please also update the new FAQ entry
http://ximbiot.com/cvs/wiki/index.php?title=CVS_FAQ#Is_there_a_way_to_change_the_versions_of_files_to_2.X.3F 

Thanks]]
>  
>
> Alternatively I could just create a new repository and keep the old one
> around just-in-case.
>
>  
>
> Any suggestions greatly appreciated.

first start by making a GOOD backup of the CVS repository, and it might be a 
good idea to do the same for the new code too.

Assuming there may be some reason to reference the 1.X development.
Tag the current repository with DEV_1_X_end, in case for some reason you EVER 
need to come back to it, so you can place a branch at that set of revisions 
and do more 1x work on that branch.

If the new code is not in a CVS sand box, I would be tempted to import it, and 
then tag it, but import is a little tricky.  The best bet would probably be to 
checkout a new sandbox (with the 1.x code),
find out which files in 1.x do not exist in the new code and issue `cvs remove 
-f` and `cvs commit` on each of those files.
make a list of which files in 2.x do not exist in the 1.x code.
copy all the files from the 2.x tree into the 1.x tree (don't miss any).
issue `cvs add` on all the new files in the list (mind the binary files -kb)
issue `cvs commit`
issue `cvs tag DEV_2_X_begin`
swear to never allow development to occur outside the control of a version 
control system again. :)

If the new code is in a CVS sand box, hopefully some one has already done the 
removes and adds (correctly) so all you need to do is
issue `cvs commit` `cvs tag DEV_2_X_begin`


Good luck.

[0] http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_4.html#SEC47
[1] http://lists.gnu.org/archive/html/info-cvs/2005-09/msg00038.html
[2] http://lists.gnu.org/archive/html/info-cvs/2004-12/msg00210.html
[3] http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_4.html#IDX97
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter