Microsoft Software
- Installed Microsoft Visual Studio.NET 2003
- Installed Microsoft Installable File System
- Installed MKS Toolkid
- Changed script to resolve dependancies with new system
- Updated env.pm to use cygpath
This entry will serve as documentation for making a new Windows build server for RIMF
Remove Empty Branch Trigger: This trigger removes the branch and the zero element that is left when a user checks out an element on a branch then cancels the checkout. Normally this causes a branch with only a zero element which is identical to the version from which it was branched. Essentially this empty branch is useless. This trigger prevents that.
Not only is this empty branch useless but:
I'm experiencing that last bullet item right now. At one time I was attempting to do a delivery for somebody from another stream, first rebasing my stream. The delivery was unsuccessful and it was decided that this other engineer would work on it and deliver himself. So I canceled the delivery. One would think then that my view was relatively clean.
However now I want to deliver something else and I see this old rebase activity hanging around. In looking into the change set I notice a bunch of items from that older attempt at delivering. Why were these still hanging around? I had canceled that delivery right?
Well I believe the problem comes from having empty branches. Take for example the following:
It shows a rebase from osaka/5 -> defaria_osaka/1. Yet these two version compare to be the same! How did this happen? Well think about it. Prior to the rebase I had an empty branch (i.e. I had defaria_osaka/0 left over from the canceled delivery which merely did an unco). This means that osaka/4 and defaria_osaka/0 were identical. Then osaka/5 came into existance. Now 4 != 5 and when I rebase Clearcase has to propogate osaka/5 creating defaria_osaka/1. Now I have two identical versions and associate meta data and all for naught! Additionally I have a baseline lable on defaria_osaka/1 which give the air of importance to this unimportant version.
Had we had a remove empty branch trigger, when the delivery canceled, the unco would have left defaria_osaka/0 and the remove empty branch trigger would have removed the empty branch. Then my view would have been pointing to osaka/4 (and would have moved to osaka/5 if I were using .../osaka/LATEST and a dynamic view or updated to osaka/5 during the normal course of updating the view). Indeed, allowing empty branches to persist can cause developers to unknowingly get "stuck in time".
I haven't been keeping this up lately but I've decided to resume my status even if I don't use this as my actual status report.
First I'll try to catch up by summarizing what I've been working on lately. Mostly I've been working on this CIT (Continuous Integration and Test) Perl script. CIT is basically an controlling script that calls other build scripts in use here. The idea was to have this script continually build the software, if it needs to build. A primative form of build avoidance is implemented in that a cleartool update is done and if no files are updated in a particular component then that component will not be built.
Some of its characteristics include:
Worked a lot on a script to drive the building. This script, called build, utilizes a configuration file as well as command line parameters to support adhoc kind of building (e.g. "Start a build but only build component X, noclean and do the testing, etc.).
Recently added what is called CIT (Continuous Intergration and Test) option as well as some build avoidance at the component level (utilizing the output from cleartool's update command). With --cit turned on the build script will attempt a build by first updating the view. It will then parse cleartool's update log. If nothing new came in for the component then the assumption is made that the component does not need to be rebuilt and skips it. After all components are built, streamBuild.pl will do other things like publishing and testing, etc. Next build will make a baseline (IFF the streamBuild.pl returns 0 status and at least one component was built) as well as update change logs on the web page.
When all of that is done, build will wait for 5 minutes and then restart itself.
Worked out a nasty bug where build was using chdir but streamBuild.pl was using $ENV {PWD}. Turns out that chdir does not change $ENV {PWD}. Fixed by doing "use Cwd qw(chdir)" which effectively sets $ENV {PWD} when chdir is called.
WARNING: Found out that streamBuild.pl was not that robust and does not return non zero status for some failures. For example, if it is not able to run unitTests it still might return a 0 status. This is bad. The streamBuild.pl script will have to be investigated and made to return good exit codes.
I'm back at HP, this time in Pleasanton working for the ILM doing Clearcase, Clearquest and release management. This division seems to rely heavily on an internal WIki for much of their documentation and process flow. Spent the first few says getting set up, installing my environment, getting logins, etc. Saw a requirement for an Evil Twin trigger so I offered up mine. Seems mine was not tested all that well under Unix and I had to change some things to remove the vob tag prefix. Also, handling of clearprompt on Unix is a little problematic. Seems that clearprompt is not gui oriented unless you specify -prefer-gui and even then it acts irratic because it does not pay attention to "\n" to represent new lines so I stuck with the non gui specification under Unix.