[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating Old Repository

From: Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code 6067
Subject: Re: Updating Old Repository
Date: Wed, 20 Jun 2007 08:28:40 -0500
User-agent: Thunderbird (X11/20070221)

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
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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]