Thanks Todd.
I'm not sure whether it was hotmail or me typing my emails in Windows Notepad first and then pasting them into hotmail chopping the eol's?! I'm an SCM/Release Mgr and never touch or modify any source code, so basically my sandbox or working folders are pretty much clean except the build.xml's and property files which I modify locally. But now that you explain your method more in details, I like it and I may adopt some of it into my release process. thanks again. > Date: Tue, 24 Feb 2009 13:17:29 -0500 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: Script Help > > BTW, Your replies are a little better now. Thanks for changing what ever it > was. > > Rez P wrote, On 02/24/2009 12:33 PM: > > Thanks for taking time and your thorough explanation and examples. > > > > I usually do a general or selective update to my > > CVS working folders and get only the files that > > need to go into a build and tag the CVS module > > only if a build is successful. > > > So at this point we have *A* tag, that should match cvs_stat.log. > > > > Then do a 'cvs -f stat > cvs_stat.log' > > which shows my working revisions vs. repo revisions and > > I then pack the generated file into the war file as a record. > > I was hoping that there was a way to generate a log that > > only shows my working copy files and their full path and > > their file revisions and I could do away with all the extra > > info that cvs -f stat generates. > > > > Do you mean some kind of summary from 'cvs log' here? > > > > > I prefer to tag CVS after doing a build. > > What if the build keeps breaking? > > keep making test tags, they are cheap. > > > Then each time until it's fixed, > > I have to do more steps tagging or moving the tags to the new > > fixed files as they're checked in, > > and many times I've forgotten to retag, > > therefore, fetching the wrong revs. > > I think the fundamental difference you and I have here is that you do release > builds from your sandbox. > > I only do them from checked out tags[1]. which means I get my sandbox > working, tag it (test_tag), move the the release build directory(RBD), clean > the RBD, checkout based on the tag and build. If everything built and worked > correctly in the RBD, I apply a release build tag (RBT) to the test_tag, and > truly do a release from the RBT, i.e., I do another clean checkout, but using > the RBT and release that. my method makes sure that everything is required > for the build IS in CVS. > > > [1] When I am the Configuration Manager, I check out code, never make it. > Making it all work together is the teams job, I'll let them know where they > are failing in that task. BTW part of the reason I take this hard line build > directory separation is that when I am working alone, it keeps me from making > too many mistakes. > > > This method works for me better than tagging first > > then checking out based on a tag. > > Utlimately, shouldn't the files in a working folder > > which contributed to a successful build be tagged? > > Which you can not guarantee if you did not check the tag out into a clean > directory, i.e., there may be a file in your sandbox that is working and not > yet in CVS. > > > I suppose either way results in the same outcome but the latter, > > as I described, > > leaves too much room for mistakes in my case it involves more work. > > Technically, if you tag a module in the repository first then check > > out based on the tag, what happens, > > does CVS take a quick snapshot of the repository state and then tags it > > and during this time no one can check out and repository > > transaction would be slightly slower than normal? > > > > My script below does make one assumption about my group's work process: > 1) on release days the head of the trunk or branch which we are releasing > from, *SHALL* be: > up to date, > compilable, > as we intend to release. > 2) which has the following set of changes to work process: > If you are not involved in the code that is getting released, you'll either > keep it in your sandbox or you'll make your own [sub]branch to work while we > cut the release. > If you are involved in the code that is getting released, > you'll check in only working code in the release trunk|branch > you will not experiment or work on future features while in the release > trunk|branch. > > > >> Date: Tue, 24 Feb 2009 11:59:09 -0500 > >> From: [email protected] > >> To: [email protected] > >> CC: [email protected] > >> Subject: Re: Script Help > >> > >> Rez P wrote, On 02/23/2009 07:41 PM: > >>> I'm curious as to how other build engineers keep a log, > >>> do you run cvs stat or cvs log also? > >>> Is there a cvs command to print only the path and revsion > >>> number without resotry to scripting? > >>> > >> I assume you are trying to have a method to pull back from CVS exactly > >> what > >> was built for a release. > >> > >> 1) use tags, they will make your life easier and sanity last longer. > >> > >> 2) use the following method: > >> cd /tmp/ > >> cvs checkout baselinename > >> cvs tag build_tag_bla baselinename > >> cvs release -d baselinename > >> > >> cd /where/you/usualy/make/release/builds > >> cvs checkout -rbuild_tag_bla baselinename > >> #and for your method of sanity, even though it is no longer needed. > >> cvs -f stat | grep "Repository revision" | gawk '{print $4 " " $3}' > >> cd baselinename > >> make\ant\buildsystem world > >> > >> sleep better. :) > >> > >> I have posted partial scripts to this list in the past for doing part of > >> this > >> work. > >> -- > >> Todd Denniston > >> Crane Division, Naval Surface Warfare Center (NSWC Crane) > >> Harnessing the Power of Technology for the Warfighter > >> > >> > > > > _________________________________________________________________ > > Windows Live™ Hotmail®:…more than just e-mail. > > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_022009 > > > -- > Todd Denniston > Crane Division, Naval Surface Warfare Center (NSWC Crane) > Harnessing the Power of Technology for the Warfighter _________________________________________________________________ It’s the same Hotmail®. If by “same” you mean up to 70% faster. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Same_022009
