Script Help

[Rez P]

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 realize now that my build log generated from CVS stat output has been incorrect. I've been executing the below command

cvs -f stat | grep "Repository revision" | gawk '{print $4 " " $3}'

and I've been keeping track of the repository versions instead, that are useless to me. I need to know the exact revisions of my local working folder contributing to my build and generate a log based on them but I find myself at a loss as to how to grep for 2 items at the same time from the result of 'cvs stat' and pass it to gawk, as listed below?!

EXCERPT:
===================================================================
File: doc - help.doc Status: Up-to-date

Working revision: 1.1
Repository revision: 1.1 /source/help_files/doc - help.doc,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: -kb

===================================================================


I would like my log to show, "Working Revision:" The file path from the line below it and the version number next to working revision or just path and working rev, something like:

.
.
Working Revision: /source/help_files/doc - help.doc,v 1.1
.
.

Thanks for your help

Rez
_________________________________________________________________
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

[Todd Denniston]

Post by Rez P
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.

[Rez P]

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


I prefer to tag CVS after doing a build. What if the build keeps breaking? 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. 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? 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?




Thanks



Rez

Date: Tue, 24 Feb 2009 11:59:09 -0500
Subject: Re: Script Help

Post by Rez P
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.
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]

BTW, Your replies are a little better now. Thanks for changing what ever it was.

Post by Rez P
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.

Post by Rez P
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?

Post by Rez P
I prefer to tag CVS after doing a build.
What if the build keeps breaking?

keep making test tags, they are cheap.

Post by Rez P
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.

Post by Rez P
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.

Post by Rez P
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.

Post by Rez P

Date: Tue, 24 Feb 2009 11:59:09 -0500
Subject: Re: Script Help

Post by Rez P
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.
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

[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
Subject: Re: Script Help
BTW, Your replies are a little better now. Thanks for changing what ever it was.

Post by Rez P
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.

Post by Rez P
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?

Post by Rez P
I prefer to tag CVS after doing a build.
What if the build keeps breaking?

keep making test tags, they are cheap.

Post by Rez P
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.

Post by Rez P
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.

Post by Rez P
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?

1) on release days the head of the trunk or branch which we are releasing
up to date,
compilable,
as we intend to release.
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.

Post by Rez P

Date: Tue, 24 Feb 2009 11:59:09 -0500
Subject: Re: Script Help

Post by Rez P
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.
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

[Korry Douglas]

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?

Also see the excellent utility cvs2cl (CVS to ChangeLog) at http://www.red-bean.com/cvs2cl/


-- Korry