RE: Updating Old Repository

[Huber, Robert]

What I was wondering about was starting the version numbering scheme
afresh with 2.1 not changing 1.x versions to 2.x. But the tag may work
just as well?

-----Original Message-----
From: Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code 6067
[mailto:address@hidden 
Sent: Wednesday, June 20, 2007 9:29 AM
To: Huber, Robert
Cc: address@hidden
Subject: Re: Updating Old Repository

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_ch
ange_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
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.