Status for Andrew DeFaria

• Installed and tested licenses from new server
• Examined and transfered crontab entries from sons-clearcase -> sons-sc-cc
• Performed chmaster from sons-clearcase -> sons-sc-cc
• Reinstalled Cygwin and got rsh and smake working again

Time spent: 3 hours

Licensing

I've installed the license strings into sons-sc-cc. They seem to work with no problem. Note that people will need to adjust their license server setting as follows:

1. Go to Control Panel: Clearcase
2. Click on Licensing tab
3. Change sons-clearcase -> sons-sc-cc

Note: Shanghai users will also need to do this!

Crontab (ctmerge)

I've copied the ctmerge cronjobs from sons-clearcase -> sons-sc-cc. Somebody will need to create the corresponding views on sons-sc-cc and uncomment out the ctmerge commands in crontab. The problem is that ctmerge requires a view to merge too and nobody created these views on the new machine. The entries look like:

#00 07 * * * //sons-sc-cc/Views/official/Tools/bin/ctmerge -view /dview/3.2.ccadmin
-branch china_3.2

As you can see it's commented out. As I said ctmerge requires a view to merge to. So somebody needs to create a 3.2.ccadmin view then do a ct startview to insure it's started, then crontab -e and uncomment the line. Repeat for other ctmerges you need to have running.

Chmaster

I performed the chmaster -all to change mastership of all objects over to sons-sc-cc. There were some errors due to the fact that some of the objects were locked. I'm cleaning that up... OK all mastership is now at sons-sc-cc so you should be able to use sons-sc-cc as if it was sons-clearcase. This means that the old config specs should work (i.e. things using branches like rel_3.2 should now work on sons-sc-cc).

Smake now working again!

I reinstalled Cygwin and got rsh sons-sc-cc <cmd> working. This means that smake should now work like it used to. I also changed site_parms.US to specify sons-sc-cc as the build server. This means that people using smake should see their builds happening on sons-sc-cc instead of sons-clearcase.

Last bits of wrap up

For now I've left sons-clearcase running. This will allow you to continue running as people switch their license serving over to sons-sc-cc. After you believe everybody's successfully using sons-sc-cc and no longer using sons-clearcase I suggest you RDP to sons-clearcase and simply stop Clearcase in the Clearcase control panel. Let that settle for about a week. Anybody who didn't migrate to sons-sc-cc will surely report the problem.

After this period I suggest I get back in there and perform a few rmreplica commands to tell Multisite that the replicated vobs on sons-clearcase no longer exist. This will signal sons-sc-cc and sons-cc to no longer send packets to sons-clearcase to update it's replicas of the vobs.

At that point sons-clearcase is essentially out of the loop and can be decommissioned.

Posted by Andrew DeFaria at 05:31 PM | Permalink

• 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

Microsoft Installations

Installation of Visual Studio.NET and the Installable File System took forever mostly due to the fact that I was installing is off a share from Roseville.

MKS Toolkit

After installing MKS Toolkit I went back to turn off the various services it installs that conflicts with Cygwin. The streamBuild.pl process uses Cygwin so we need that too. I'm not particularly impressed with MKS Toolkit. For example, before MKS installed I tried executing a few of the executables that had been installed already. Each popped up with a dialog box saying it couldn't get a license. Fair enough as the installation had not yet finished. However, this does mean that each time an executable is executed additional work needs to be done to check the license.

In general MKS seems clunkier than Cygwin and less complete. Of course I am biased and unfamilar with MKS. For example, I don't know how MKS handles /etc/passwd and mapping of uids to sids.

D2R.sh script

Not many changes needed to be made to D2R.sh, the new, shortened name for osaka_strm_build_D2R.sh, as it was already parameterized fairly well. Some of the INCLUDE environment variable settings changed to accommodate the new locations on the new system.

Changes to env.pm

With this new system I decided to go with changing /cygdrive -> /dev - shorter, more convenient, etc. However env.pm was still incorrectly attempting to change drive letter references with /cygdrive and handling it's own path name conversion. Changed this to use cygpath as that's a better way to do this. Plus it takes into account if the user has change the cygdrive prefix.

Posted by Andrew DeFaria at 10:26 AM | Permalink

This entry will serve as documentation for making a new Windows build server for RIMF

• New machine received with Windows 2003 XP (SP 1?) installed
• Install Clearcase 2003.06.00
• Installed Microsoft Visual Studio.NET 2003
• Installed Cygwin
• Installed JDK 1.4.2

Clearcase Install

Clearcase install went relatively flawlessly.

Cygwin Install

Made sure my Cygwin repository is up to date. Installed Cygwin on new server. Seems the build process uses ksh so I insured that ksh was indeed installed. I think that ksh was the essence of the MKS Toolkit requirement. Going to try to see if I can skip the installation of Perl (ActiveState) and instead just use Cygwin's. This may be problematic and I believe there are Perl scripts in the build process that assume that ActiveState Perl is installed as it explicitly does `rd <dir>` and ActiveState runs that with cmd while Cygwin's Perl uses sh. As rd is not a command, rather a built in for cmd, this fails. Relying on such things is the essence of non portable code...

Microsoft Visual Studio 2003 .NET

Unable to access share where Microsoft Visual Studio.NET 2003 installation exists!

Posted by Andrew DeFaria at 02:48 PM | Permalink

• Documented problems with empty branches

Empty branches and the mess they create

Did you know that we have been creating empty branches that then cause unnecessary and additional work for Clearcase when rebasing or delivering as well as unnecessarily clutter version trees? What is an empty branch you ask? Well when working on a stream (or a simply a branch in base Clearcase terms) if a user checks out a file a branch is created (e.g. defaria_osaka) and a copy of the current element is made the 0 version on the new branch, then that 0 version is checked out. It looks like this:

But if the user decided not to change anything and cancels the checkout (which can also happen if the user cancels a rebase or delivery) then Clearcase will cancel the checkout but the view will remain focused on the 0 version (e.g. defaria_osaka/0):

This version is essentially useless as it is the same as the version it branched from (e.g. osaka_strm/1) however this 0 version can be labeled (i.e. have a baseline applied to it) and that starts making it seem more important than it really is.

But what's worse is that if development continues on osaka_strm, producing osaka_strm/2 or 3, etc., then rebase then needs to merge this new osaka_strm version to defaria_osaka thus producing defaria_osaka/1. Essentially at this time osaka_strm/2 == defaria_osaka/1. Still a new version is produced on defaria_osaka thus creating more meta data for Clearcase to retain, manage and display in things like the Version Tree Browser, etc. So, for example:

Here is an example of an empty branch growing into a useless rebase. At osaka_strm/1 a checkout was done to defaria_osaka creating defaria_osaka/0 and a checkout. Later the checkout was canceled making defaria_osaka/0 - an empty branch. At this point osaka_strm/1 and defaria_osaka/0 are the same.

Then osaka_strm marched onward producing versions 2, 3 and 4. When rebasing Clearcase noticed the defaria_osaka/0 was old compared to the new osaka_strm/4 so it merged it producing defaria_osaka/1. Now defaria_osaka/1 is the same as osaka_strm/4. But there has been no development on my defaria_osaka view with respect to this element! Why then do I have or need anything on a defaria_osaka branch for this element? And why am I producing more versions for something I'm not touching? For a rebase that I'm doing I have hundreds of these...

This effect causes Clearcase to consider more elements when rebasing and delivering. Also version trees are needlessly more cluttered. Finally users can be confused when they rebase or deliver because they are seeing many elements and activities involved in the rebase or deliver that, as far as they are concerned, they had nothing to do with.

These empty branches and subsequently created versions are non-essential as none of them represent new work, carry along extra meta data, cause additional work for Clearcase and confuse users.

Normally I suggest and implement a remove empty branch trigger. This trigger is fired on the rmbranch and uncheckout events. It checks to see if the uncheckout would result in an empty branch and if so it removes the branch thus eliminating all the problems mentioned above.

Posted by Andrew DeFaria at 12:23 PM | Permalink