[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Updating Old Repository
RE: Updating Old Repository
Wed, 20 Jun 2007 10:47:38 -0400
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?
From: Denniston, Todd A CIV NAVSURFWARCENDIV Crane, Code 6067
Sent: Wednesday, June 20, 2007 9:29 AM
To: Huber, Robert
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
to checkout. With watches I suppose you may need to issue cvs edit on
> 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
> from there.
you can assign a revision .
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
Ignore the cvs _revision_ information, it is for CVS's use only. By
the cvs revision information you may run the risk of breaking
cvs code has about things being on the 1.x revision set and no those
assumptions are not documented any where.
Use tags (symbolic names )for the humans, i.e. if you want the set of
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
[[ If any of our long time readers has significant changes that should
to the above comments, please also update the new FAQ entry
> Alternatively I could just create a new repository and keep the old
> around just-in-case.
> Any suggestions greatly appreciated.
first start by making a GOOD backup of the CVS repository, and it might
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
need to come back to it, so you can place a branch at that set of
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
then tag it, but import is a little tricky. The best bet would probably
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
-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
issue `cvs commit`
issue `cvs tag DEV_2_X_begin`
swear to never allow development to occur outside the control of a
control system again. :)
If the new code is in a CVS sand box, hopefully some one has already
removes and adds (correctly) so all you need to do is
issue `cvs commit` `cvs tag DEV_2_X_begin`
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.