Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Single most dangerous pitfall:</p> <p>Once a component is defined, you cannot move an element outside of this component (you can copy it and re-create it elsewhere, but you will loose its history)</p> <p>Single most useful best-practice:</p> <p>Understand well the nature of an UCM component: it is about <strong>coherency</strong>.<br> A component is a set of file which:</p> <ul> <li>evolves as a single unit, </li> <li>is labeled (baselined) as a whole, </li> <li>is branched as a whole.</li> </ul> <p>If you can make evolutions without touching another group of files, chances are you have two components.</p> <p>Example of components:</p> <ul> <li>an application (or a autonomous part of an application)</li> <li>a technical library</li> <li>a packaged set of file (for release)</li> </ul> <p>The one document that should guide you to define components is the <strong>Applicative Architecture</strong> (which takes the business and functional specifications and project them onto applications which will then be specified at the technical level and implemented).</p> <p>When all those components are defined, you have two approaches to manage them:</p> <ul> <li><p><strong>system approach</strong> (every components is writable in a UCM project): useful for starting a project, but cumbersome with legacy project: you do not need to put a baseline on each and every components simply because 3 files has changed in one of those components.</p></li> <li><p><strong>component approach</strong>: one or two writable components, the rest is there only as <em>non-modifiable</em> component. This is a scalable approach, allowing you to define one project per-component to develop, with a "fixed configuration" (i.e. "the other baselines", representing fixed states of the non-modifiable components you need to have in order to compile the modifiable one. You can change at any time this configuration, that is you can rebase the foundation baselines of the non-modifiable component whenever you want).</p></li> </ul> <p>You can define as many Projects and Streams you want, allowing you to easily visualize the <a href="https://stackoverflow.com/questions/216212#216228"><strong>merge workflow</strong></a>. </p> <p>Remember: a Stream represents a <strong>development effort</strong>.<br> Do not call a Stream after a resource (like <code>VonC_stream</code>), but after a task or set of tasks to do in that Stream (as in <code>APP_LCH_R32_Dev</code>: Development for 32th release of my App Launcher)</p> <hr> <p>Note: UCM is just some meta-data on top of ClearCase: even if a group of file is defined as a UCM component, nothing prevents you to still making classic non-UCM branches, checkouts or checkins (in non-UCM views).</p> <hr> <blockquote> <p>Is there a danger in creating too many fine grained components or having too many dependencies between components? </p> </blockquote> <p>Yes, that is why Applicative Architecture is important. Again, once a component is defined, you cannot move elements between those components. </p> <p>Another details to know about components is their layout:</p> <pre><code>myVob myComponent1 myComponent2 myComponent3 </code></pre> <p>A root component is always at the first level below a Vob.<br> You also can define a component as a all Vob but I would not recommend it (adding a Vob put stress on your Vob server. Adding a directory <em>within an existing Vob</em> cost nothing)</p> <p>That means if you define some technical libraries as components, you cannot go as:</p> <pre><code>myLibs Apache ant xalan xerces </code></pre> <p>but will have to do:</p> <pre><code>myLibs apapche_ant apache_xalan apache_xerces </code></pre> <hr> <p>Final warning: <strong>dependency</strong> (the true mark of a <em>configuration</em> management system)</p> <p>One of the main advantage of UCM (or so I thought at the time -- 2003 --) is dependency.<br> If <code>A</code> depends on <code>B</code>, and I put <code>A</code> in my project, it will automatically include <code>B</code> in the same project.</p> <p>Magic.</p> <p>But it is broken.</p> <ul> <li>First, never do root-based dependency (a root-based component is a set of file). It will break at the first overlap:</li> </ul> <pre> A1 B1 B2 </pre> <p>Here you need <code>B2</code> to go on building <code>A</code>, but <code>A</code> starts from <code>A1</code> based on <code>B1</code>: <code>B2</code> overrides <code>B1</code>. As soon as you put a baseline on <code>A</code> (<code>A2</code>), it is over. You will not be able to change B anymore. <code>A</code> parasite baseline (called <code>A2</code>!?) will have been put on the (non-modifiable!) component <code>B</code> because of the overlap.</p> <ul> <li>Always include your dependencies in a rootless component</li> </ul> <pre> ADep1 A1 BDep1 B1 BDep2 B2 </pre> <p>Here you have rootless components <code>ADep</code> and <code>BDep</code> (a rootless component is a special component which aggregates other rootless or root-based components)<br> You still have an override, but this time between rootless components.<br> That will still make a parasite baseline (on <code>BDep</code>, called <code>A2</code>), but at least you will be able to rebase <code>BDep2</code> into other baselines later (<code>BDep3</code>, <code>BDep4</code>...)</p> <p>More on this <a href="http://www.ibm.com/developerworks/forums/message.jspa?messageID=13798284#13798284" rel="nofollow noreferrer">Incoherences and Inconsistencies of ClearCase UCM</a>, with <a href="http://www.cmcrossroads.com/forums?func=view&amp;catid=31&amp;id=58775#58779" rel="nofollow noreferrer">Rational counter-arguments here</a> (and just after that their post, proof that their arguments are not very good to say the least).</p> <p>Read also <a href="https://stackoverflow.com/questions/449549/how-to-leverage-clearcases-features/449810#449810">How to Leverage Clearcase’s features</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload