RE: branch removal question
Title: branch removal question I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? If I need to supply more information please let me know, I would be glad to. Thanks, Don Butts -Original Message-From: Don Butts [mailto:[EMAIL PROTECTED]Sent: Friday, June 18, 2004 9:45 AMTo: [EMAIL PROTECTED]Subject: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
Don Butts wrote: I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? How about, this requires a few more brain cycles than were available at the time? :=) -Original Message- We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. I wouldn't remove the branches. I'm always reluctant to remove anything from the history. Instead of checking out branches, it might be easier to apply non-branch tags instead. This means fewer branches to deal with. I'm guessing the reason you're using a branch is because the update command remains the same, e.g. cvs update -r PROD (where PROD is a branch tag). Basically, what you would do is to create a non-branch tag indicating the currently-tested and working version, e.g. cvs tag REL_2_0_2. Then, you can move the PRODUCTION tag using the -F option to tag. Let me know if I'm not being clear (I haven't had my morning coffee yet ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: branch removal question
Don Butts wrote: Content-Type: multipart/mixed; boundary1243246784== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. Confused, one or 2 CVSROOTs? do you mean `patch patchfile` or `cvs update -jsomething -jsomethingelse` (generally called a merge) When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time Why remove it? You loose history when you remove things (actually delete information from repo files), which is pretty much against having a version control system in the first place. why not create preprod`date +%Y_%b_%d` branches when you want to go into QA, so you have all the information that lead up to each release. (next question is a more personal process, not general practice) and why are the production releases not just (normal) tags on the QA branch(es), where the QA people have said this set of files is correct for release.? Of course you _might_ want to branch at that normal tag too if you need to do several fixes to the released version and then merge back to that QA branch when the fixes are ready to be QAed. I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts -- 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
RE: branch removal question
Normally one would apply a tag to the versions that are ready for testing, and update the tag as bugs are fixed. Then apply a second tag to the code that reaches production quality. To apply the second tag, use the cvs rtag -r option. The bummer with this is that if you make bug fixes in your test environment, you must run an additional cvs update command on each modified file due to stickiness issues in with the tags, but it's a minor annoyance that's overcome with experience. And you must remember to apply the testing tag to the committed fixes, a part of the process that might easily be forgotten. --- Forwarded mail from [EMAIL PROTECTED] I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? If I need to supply more information please let me know, I would be glad to. -Original Message- From: Don Butts [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 9:45 AM To: [EMAIL PROTECTED] Subject: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
--- Forwarded mail from [EMAIL PROTECTED] Don Butts wrote: I asked this question last Friday but got no response. Was it poorly asked, not enough information, too ignorant for words? I wouldn't remove the branches. I'm always reluctant to remove anything from the history. Instead of checking out branches, it might be easier to apply non-branch tags instead. This means fewer branches to deal with. I'm guessing the reason you're using a branch is because the update command remains the same, e.g. cvs update -r PROD (where PROD is a branch tag). Basically, what you would do is to create a non-branch tag indicating the currently-tested and working version, e.g. cvs tag REL_2_0_2. Then, you can move the PRODUCTION tag using the -F option to tag. Floating tags can also be used. For example, create a tag called PRODUCTION and apply it to the next release. Then just run cvs update in the production area, and the proper versions will appear. The down side to this is that if you don't apply unique tags in addition to the floating one, you can't go back if something breaks. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: branch removal question
[EMAIL PROTECTED] wrote: Floating tags can also be used. For example, create a tag called PRODUCTION and apply it to the next release. Then just run cvs update in the production area, and the proper versions will appear. Yep, that's basically the idea I was trying to get across. The down side to this is that if you don't apply unique tags in addition to the floating one, you can't go back if something breaks. Yes, that's a very important point. So, to summarize, I think we're in agreement in recommending this procedure: There are two floating tags. For discussion's sake, I will call them: QA_VERSION PRODUCTION The tag QA_VERSION is applied to a version that is ready to go to QA. The tag PRODUCTION is applied to a version that is ready to go into production. When a version is ready for QA, a unique tag is applied. I usually recommend that the tag incorporates the version number and build number, e.g. for rev. 2.1 build 17 of a project named PROJECT, the tag might look like PROJECT_2_1_17. The QA_VERSION tag is applied to that version, using: cvs rtag -rPROJECT_2_1_17 -Ff QA_VERSION project (or, if you prefer, 'cvs tag -rPROJECT_2_1_17 -Ff QA_VERSION' ) When the QA version is ready for production, then the production tag is applied, using: cvs rtag -rQA_VERSION -F PRODUCTION project During the maintenance window, the QA version is promoted to production by simply issuing a 'cvs update -dP' command. Don, feel free to disagree or to point out anything we may have missed ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
branch removal question
Title: branch removal question We are using cvs in somewhat of a non-standard way. We have a production cut of our compiled source that we deploy via cvs using a production branch. The application does not mind the fact the CVS control files co-exist within the source and the application runs fine. When we want to patch production we first patch the same branch in a different checkout area and then commit it. When it comes time to upgrade the production area we bring down the application during a maintenance window and perform a cvs update in the production area. This has worked great for more than a year so I am very happy with this process. We were basically mimicking this process in a pre-production area for QA purposes and while this has worked OK we are having a bit of trouble keeping these two branches in sync. So, I know that I can remove a branch via the cvs admin -n command and I am wondering if a better process would be to remove the preprod branch every time I move a new patch to production and when it comes time to test the next patch just recreate the preprod branch off of the current prod branch. I have performed some tests using this method and all seems to work fine but I thought that I would ask the opinion of those who have been using CVS a lot longer than I. Thank you for your time, Don Butts ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
