RE: Script Help

[Rez P]

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: address@hidden
> To: address@hidden
> CC: address@hidden
> 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: address@hidden
> >> To: address@hidden
> >> CC: address@hidden
> >> 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. Get your account now.