defaria.com/blogs/Status/archives/2006_07.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml"$>" />
  11
  12    <title>Status for Andrew DeFaria: July 2006 Archives</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/2006_06.html" title="June 2006" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/2006_09.html" title="September 2006" />
  17 </head>
  18 <body class="layout-one-column">
  19    <div id="container">
  20       <div id="container-inner" class="pkg">
  21
  22          <div id="banner">
  23             <div id="banner-inner" class="pkg">
  24                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  25                <h2 id="banner-description">Searchable status reports and work log</h2>
  26             </div>
  27          </div>
  28
  29          <div id="pagebody">
  30             <div id="pagebody-inner" class="pkg">
  31                <div id="alpha">
  32                   <div id="alpha-inner" class="pkg">
  33
  34                      <p class="content-nav">
  35                         <a href="http://defaria.com/blogs/Status/archives/2006_06.html">&laquo; June 2006</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/2006_09.html">September 2006 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">July 15, 2006</h2>
  44                      <a id="a000561"></a>
  45                      <div class="entry" id="entry-561">
  46                         <h3 class="entry-header">Clearcase Migration</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <ul>
  50   <li>Installed and tested licenses from new server</li>
  51
  52   <li>Examined and transfered crontab entries from sons-clearcase -> sons-sc-cc</li>
  53
  54   <li>Performed chmaster from sons-clearcase -> sons-sc-cc</li>
  55
  56   <li>Reinstalled Cygwin and got rsh and smake working again</li>
  57 </ul>
  58
  59 <p><b>Time spent:</b> 3 hours</p>
  60
  61                               <h2>Licensing</h2>
  62
  63 <p>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:</p>
  64
  65 <ol>
  66   <li>Go to Control Panel: Clearcase</li>
  67
  68   <li>Click on Licensing tab</li>
  69
  70   <li>Change sons-clearcase -&gt; sons-sc-cc</li>
  71 </ol>
  72
  73 <p><b>Note:</b> Shanghai users will also need to do this!</p>
  74
  75 <h2>Crontab (ctmerge)</h2>
  76
  77 <p>I've copied the ctmerge cronjobs from sons-clearcase -&gt; 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:</p>
  78
  79 <div class=code><pre>
  80 #00 07 * * * //sons-sc-cc/Views/official/Tools/bin/ctmerge -view /dview/3.2.ccadmin
  81 -branch china_3.2
  82 </pre></div>
  83
  84 <p>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.</p>
  85
  86 <h2>Chmaster</h2>
  87
  88 <p>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).</p>
  89
  90 <h2>Smake now working again!</h2>
  91
  92 <p>I reinstalled Cygwin and got rsh sons-sc-cc &lt;cmd&gt; 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.</p>
  93
  94 <h2>Last bits of wrap up</h2>
  95
  96 <p>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.</p>
  97
  98 <p>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.</p>
  99
 100 <p>At that point sons-clearcase is essentially out of the loop and can be decommissioned.</p>
 101
 102                               <p class="entry-footer">
 103                                  <span class="post-footers">Posted by  at  5:31 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000561.html">Permalink</a>
 104
 105
 106                               </p>
 107                            </div>
 108                         </div>
 109                      </div>
 110
 111
 112
 113                      <h2 class="date-header">July 13, 2006</h2>
 114                      <a id="a000560"></a>
 115                      <div class="entry" id="entry-560">
 116                         <h3 class="entry-header">Microsoft Software</h3>
 117                         <div class="entry-content">
 118                            <div class="entry-body">
 119                               <ul>
 120   <li>Installed Microsoft Visual Studio.NET 2003</li>
 121
 122   <li>Installed Microsoft Installable File System</li>
 123
 124   <li>Installed MKS Toolkid</li>
 125
 126   <li>Changed script to resolve dependancies with new system</li>
 127
 128   <li>Updated env.pm to use cygpath</li>
 129 </ul>
 130
 131                               <h2>Microsoft Installations</h2>
 132
 133 <p>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.</p>
 134
 135 <h2>MKS Toolkit</h2>
 136
 137 <p>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.</p>
 138
 139 <p>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.</p>
 140
 141 <h2>D2R.sh script</h2>
 142
 143 <p>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.</p>
 144
 145 <h2>Changes to env.pm</h2>
 146
 147 <p>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.</p>
 148
 149                               <p class="entry-footer">
 150                                  <span class="post-footers">Posted by  at 10:26 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000560.html">Permalink</a>
 151
 152
 153                               </p>
 154                            </div>
 155                         </div>
 156                      </div>
 157
 158
 159
 160                      <h2 class="date-header">July 11, 2006</h2>
 161                      <a id="a000559"></a>
 162                      <div class="entry" id="entry-559">
 163                         <h3 class="entry-header">New Build Server</h3>
 164                         <div class="entry-content">
 165                            <div class="entry-body">
 166                               <p>This entry will serve as documentation for making a new Windows build server for RIMF</p>
 167
 168 <ul>
 169   <li>New machine received with Windows 2003 XP (SP 1?) installed</li>
 170
 171   <li>Install Clearcase 2003.06.00</li>
 172
 173   <li>Installed Microsoft Visual Studio.NET 2003</li>
 174
 175   <li>Installed Cygwin</li>
 176
 177   <li>Installed JDK 1.4.2</li>
 178 </ul>
 179
 180                               <h2>Clearcase Install</h2>
 181
 182 <p>Clearcase install went relatively flawlessly.</p>
 183
 184 <h2>Cygwin Install</h2>
 185
 186 <p>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 <tt>`rd &lt;<i>dir</i>&gt;`</tt> 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...</p>
 187
 188 <h2>Microsoft Visual Studio 2003 .NET</h2>
 189
 190 <p>Unable to access share where Microsoft Visual Studio.NET 2003 installation exists!</p>
 191
 192
 193                               <p class="entry-footer">
 194                                  <span class="post-footers">Posted by  at  2:48 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000559.html">Permalink</a>
 195
 196
 197                               </p>
 198                            </div>
 199                         </div>
 200                      </div>
 201
 202
 203
 204                      <h2 class="date-header">July  7, 2006</h2>
 205                      <a id="a000558"></a>
 206                      <div class="entry" id="entry-558">
 207                         <h3 class="entry-header">Remove Empty Branch</h3>
 208                         <div class="entry-content">
 209                            <div class="entry-body">
 210                               <ul>
 211   <li>Documented problems with empty branches</li>
 212 </ul>
 213
 214                               <h2>Empty branches and the mess they create</h2>
 215
 216 <p>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:</p>
 217
 218 <img alt="Empty Branch with Checkout" src="EmptyBranchCheckout.jpg" border="2">
 219
 220 <p>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):</p>
 221
 222 <img alt="Empty Branch" src="EmptyBranch.jpg" border="2">
 223
 224 <p>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.</p>
 225
 226 <p>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
 227 version is produced on defaria_osaka thus creating more meta data for Clearcase to retain, manage and display in things like the <i>Version Tree Browser</i>, etc. So, for example:</p>
 228
 229 <img alt="Unnecessary Versions" src="CreatingUnnecessaryVersions.jpg" border="2">
 230
 231 <p>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.</p>
 232
 233 <p>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...</p>
 234
 235 <p>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.</p>
 236
 237 <p>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.</p>
 238
 239 <p>Normally I suggest and implement a <a  href="/Resume/Clearcase/RemoveEmptyBranch.php"><i>remove empty branch</i></a> trigger.
 240 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.</p>
 241
 242                               <p class="entry-footer">
 243                                  <span class="post-footers">Posted by  at 12:23 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000558.html">Permalink</a>
 244
 245
 246                               </p>
 247                            </div>
 248                         </div>
 249                      </div>
 250
 251                   </div>
 252                </div>
 253             </div>
 254          </div>
 255       </div>
 256    </div>
 257 </body>
 258 </html>