Topic
25 replies Latest Post - ‏2008-09-26T21:41:30Z by jeff98air
SystemAdmin
SystemAdmin
47293 Posts
ACCEPTED ANSWER

Pinned topic Composite-baselines and their components

‏2004-12-07T21:28:57Z |
Updated on 2008-09-26T21:41:30Z at 2008-09-26T21:41:30Z by jeff98air
  • SystemAdmin
    SystemAdmin
    47293 Posts
    ACCEPTED ANSWER

    Re:Composite-baselines and their components

    ‏2004-12-07T21:28:58Z  in response to SystemAdmin
    While it's great to know whether the answer is right or wrong, I think
    it is most instructive to also know why it was wrong and perhaps what
    is the correct answer. Don't you think?

    Derek Lau
    On Tue, 7 Dec 2004 19:33:09 +0200, Ehud Ran <ehud@lmb.co.il> wrote:
    > Wrong!!!
    >
    > Regards
    > Ehud Ran
    > L.M.B.-Consulting Ltd.
    > VP Engineering
    > <mailto:ehud@lmb.co.il>
    > telephone: 054-656-0071
    >
    >
    >
    >
    > -----Original Message-----
    > From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.comOn
    > Behalf Of Deanna Peugeot
    > Sent: Monday, December 06, 2004 17:11
    > To: cciug@lists.us.ibm.com
    > Subject: RE: cciug Composite-baselines and their components
    >
    > That is correct. You create one component per baseline configuration.
    >
    > Deanna
    >
    > -----Original Message-----
    > From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.com On
    > Behalf Of ghlsecdnd
    > Sent: Monday, December 06, 2004 8:51 AM
    > To: cciug@lists.us.ibm.com
    > Subject: cciug Composite-baselines and their components
    >
    > The documentation recommends that I create a separate component to hold
    > composite-baselines (using 'mkcomp -nroot').
    >
    > Does this mean that I would need to create a separate component for each of
    > the composite-baselines if their dependencies differ?
    >
    > <============================================================
    > To unsubscribe, send email to
    > majordomo@lists.us.ibm.com and put these words in the
    > message body: unsubscribe cciug
    > ============================================================>
    >
    > <============================================================
    > To unsubscribe, send email to
    > majordomo@lists.us.ibm.com and put these words in the
    > message body: unsubscribe cciug
    > ============================================================>
    >
    > <============================================================
    > To unsubscribe, send email to
    > majordomo@lists.us.ibm.com and put these words in the
    > message body: unsubscribe cciug
    > ============================================================>
    >
    <============================================================
    To unsubscribe, send email to
    majordomo@lists.us.ibm.com and put these words in the
    message body: unsubscribe cciug
    ============================================================>
    • SystemAdmin
      SystemAdmin
      47293 Posts
      ACCEPTED ANSWER

      RE:Composite-baselines and their components

      ‏2004-12-07T22:00:46Z  in response to SystemAdmin
      The answer is simple. You can have a root less component. You create a
      dependency, connect as many components as you wish to it, and later you make
      baselines, and you get composite baselines. In another project you can use
      the same root less component, connect different components as dependant, and
      you make another composite baseline. You may think it is not a good habit,
      and if you wish you can generate a different root less component for each
      project, but it is not mandatory at all. I gave only one word as answer,
      just because the answer was so far from reality that not much should be
      said, just reading carefully the documentation.

      I saw cases when customers worked on release 1 of a system, used composite
      base line, and when they opened a new project for release 2 they created
      another root less component for making composite baseline, especially
      because the new release included new components (and some were removed). It
      was also bad and wrong! So, a root less component is a component, you can
      make many baselines and you don't need to have same configuration for all of
      them.

      Regards
      Ehud Ran
      L.M.B.-Consulting Ltd.
      VP Engineering
      <mailto:ehud@lmb.co.il>
      telephone: 054-656-0071

      -----Original Message-----
      From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.comOn
      Behalf Of Derek L.
      Sent: Tuesday, December 07, 2004 23:29
      To: cciug@lists.us.ibm.com
      Subject: Re: cciug Composite-baselines and their components
      While it's great to know whether the answer is right or wrong, I think
      it is most instructive to also know why it was wrong and perhaps what
      is the correct answer. Don't you think?

      Derek Lau
      On Tue, 7 Dec 2004 19:33:09 +0200, Ehud Ran <ehud@lmb.co.il> wrote:
      > Wrong!!!
      >
      > Regards
      > Ehud Ran
      > L.M.B.-Consulting Ltd.
      > VP Engineering
      > <mailto:ehud@lmb.co.il>
      > telephone: 054-656-0071
      >
      >
      >
      >
      > -----Original Message-----
      > From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.comOn
      > Behalf Of Deanna Peugeot
      > Sent: Monday, December 06, 2004 17:11
      > To: cciug@lists.us.ibm.com
      > Subject: RE: cciug Composite-baselines and their components
      >
      > That is correct. You create one component per baseline configuration.
      >
      > Deanna
      >
      > -----Original Message-----
      > From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.com
      On
      > Behalf Of ghlsecdnd
      > Sent: Monday, December 06, 2004 8:51 AM
      > To: cciug@lists.us.ibm.com
      > Subject: cciug Composite-baselines and their components
      >
      > The documentation recommends that I create a separate component to hold
      > composite-baselines (using 'mkcomp -nroot').
      >
      > Does this mean that I would need to create a separate component for each
      of
      > the composite-baselines if their dependencies differ?
      >
      > <============================================================
      > To unsubscribe, send email to
      > majordomo@lists.us.ibm.com and put these words in the
      > message body: unsubscribe cciug
      > ============================================================>
      >
      > <============================================================
      > To unsubscribe, send email to
      > majordomo@lists.us.ibm.com and put these words in the
      > message body: unsubscribe cciug
      > ============================================================>
      >
      > <============================================================
      > To unsubscribe, send email to
      > majordomo@lists.us.ibm.com and put these words in the
      > message body: unsubscribe cciug
      > ============================================================>
      >
      <============================================================
      To unsubscribe, send email to
      majordomo@lists.us.ibm.com and put these words in the
      message body: unsubscribe cciug
      ============================================================>

      <============================================================
      To unsubscribe, send email to
      majordomo@lists.us.ibm.com and put these words in the
      message body: unsubscribe cciug
      ============================================================>
      • SystemAdmin
        SystemAdmin
        47293 Posts
        ACCEPTED ANSWER

        Re:Composite-baselines and their components

        ‏2004-12-07T22:48:48Z  in response to SystemAdmin
        Ehud Ran wrote:
        > I saw cases when customers worked on release 1 of a system, used composite
        > base line, and when they opened a new project for release 2 they created
        > another root less component for making composite baseline, especially
        > because the new release included new components (and some were removed). It
        > was also bad and wrong! So, a root less component is a component, you can
        > make many baselines and you don't need to have same configuration for all of
        > them.

        In addition, if you have one rootless component called "TheSystem",
        you can start every project with the baseline "TheSystem_INITIAL" and
        create a completely different component dependency tree for every
        project, without needing a new (rootless) component. There is not need
        to create a new component for every project, such as "SystemA_Rel1.0",
        "SystemA_Rel2.0" or "SystemB_Rel1.0".

        Similar for non-rootless components (with VOB storage), e.g. the
        component ProjectDocumentation.

        Frank.

        TOPIC Software Group
        P.O. box 440, NL-5680 AK Best
        Netherlands
        Telefoon (+31) - 499 - 33.69.77
        Telefax (+31) - 499 - 33.69.78
        <============================================================
        To unsubscribe, send email to
        majordomo@lists.us.ibm.com and put these words in the
        message body: unsubscribe cciug
        ============================================================>
        • SystemAdmin
          SystemAdmin
          47293 Posts
          ACCEPTED ANSWER

          Re:Composite-baselines and their components

          ‏2004-12-08T19:10:53Z  in response to SystemAdmin
          Frank, could you update your CMWiki page with your explanation? I've
          pointed some people to your wiki page, only afterwards realized that
          there isn't a complete explanation of composite baselines.

          Thanks,
          David
          <============================================================
          To unsubscribe, send email to
          majordomo@lists.us.ibm.com and put these words in the
          message body: unsubscribe cciug
          ============================================================>
          • SystemAdmin
            SystemAdmin
            47293 Posts
            ACCEPTED ANSWER

            Re:Composite-baselines and their components

            ‏2004-12-09T07:36:25Z  in response to SystemAdmin
            Hi David,

            > Frank, could you update your CMWiki page with your explanation? I've
            > pointed some people to your wiki page, only afterwards realized that
            > there isn't a complete explanation of composite baselines.

            You are free update the CMWiki page yourself. I have had trouble
            defining a properuse of composite baselines myself, so I would even
            want to encourage others than myself to add explanations there.

            But as you requested, I have added my explanation.

            http://www.cmcrossroads.com/cgi-bin/cmwiki/bin/view.cgi/CM/ClearCaseUnifiedChangeManagement

            Regards,
            Frank

            TOPIC Software Group
            P.O. box 440, NL-5680 AK Best
            Netherlands
            Telefoon (+31) - 499 - 33.69.77
            Telefax (+31) - 499 - 33.69.78
            <============================================================
            To unsubscribe, send email to
            majordomo@lists.us.ibm.com and put these words in the
            message body: unsubscribe cciug
            ============================================================>
        • SystemAdmin
          SystemAdmin
          47293 Posts
          ACCEPTED ANSWER

          Re: Re:Composite-baselines and their components

          ‏2004-12-09T09:41:58Z  in response to SystemAdmin
          All that is great in an release-oriented project (a project UCM where all your main components are modifiable, your rootless component keeping tracks of all other baselines produced on the other writable components)

          In a component-oriented approch, however, composite baselines are (almost) useless.
          In such an approch, you want to add a composite baseline of a non-modifiable component in order to bring into your project that component plus all its dependencies.
          BUT: you will soon face the overlapping dependencie case:

          P1 (project UCM P1)
          S1 (Stream S1 of P1, does not matter if it is integration or development stream)
          ...Aw (means component A writable)
          ...B2 (means P1 uses non-modifiable component B, baseline 'B2')
          ...C1 (means P1 uses non-modifiable component B, baseline 'C1')
          ...|--B1 (means C1 depends on baseline B1 of non-modifiable component B, overriden by B2)

          In that configuration, when you make a new baseline on A (only writable component of project P1)... a "parasite" baseline is also created on non-modifiable component C!!! Rational claims in its misguided whitepaper that is necessary to "record the fact that C1 does really use B1 but B2"...

          If C1 is a baseline from a root-based component... you're screwed: You can not rebase or remove C anymore. ClearCase claims you have made modification(!) on stream S1...
          If C1 is a baseline from a rootless component, you can rebase forward (not backward), only in CC2003 (or with a non-official fix in CC2002), you can not rebase backward neither remove C.

          The ability to rebase forward, backward or remove a read-only component is key in UCM system. That is why I call the unwanted baseline on a non-modifiable component is a "parasite" one.

          To go further in that tweasted behaviour (where a non-modifiable component is... modified!):
          Observed with CC2003-SR0
          nrC1w (modifiable rootless component)
          |--nrB1 (non-modifiable rootless component)
          You can not add within nrC1 dependencies nrB without making nrB... writable!

          Observed with CC2003-SR3
          nrC1 (Baseline 1 of a non-modifiable rootless (nr = noroot) Component Cr)
          |--A1 (non-modifiable component with baseline A1 added
          nrC (rootless component C) should be declared writable... and it seems it is no longer possible!
          ct chproj -amod nrC@\tpvob pnr@\tpvob
          cleartool: Warning: Skipping component "nrC". This component stores only baselines, not file e
          lements, and cannot be modified directly by users.
          Changed modifiable component list and propagated changes to streams in project "pnr@\tpvob".
          And this is another ironic twist: ClearCase refuses to make explicitly a component modifiable even though ClearCase consider nrC writable and produced baselines on it.
          So the new policy (2003-SR3) seems to consider any rootless component non-modifiable, even if ClearCase continue to produce baselines (justified or not) on them.
          Of course, all of this is utterly not-documented

          Same kind of story if you do a "mkbl -all -identical" (baselines are created on non-modifiable components as well as modifiable ones, whether there are composite dependencies or not)

          In short, UCM is :
          • incoherent (I want to rebase a non-modifiable componenent and I can not, ClearCase claiming I have done modifications on the current stream!)
          • inconsistent (ClearCase modifies non-modifiable component, or keep writable component as "non-modifiable")

          I have been working on it with a very reluctant Rational support for 20 months now...
          daniel.chaffiol@sgcib.com
          • SystemAdmin
            SystemAdmin
            47293 Posts
            ACCEPTED ANSWER

            Re:Re: Re:Composite-baselines and their components

            ‏2004-12-09T23:17:58Z  in response to SystemAdmin
            Hi Daniel,

            I am SO GLAD and also SO SAD about your reply.

            It is exactly what I have been struggling with for the past 2 years,
            with various different customers. (I work as a consultant for
            different customers). I have tried to explain to Rational support
            about it, but in vain.

            I even talked to the Product Manager of UCM about it, several times
            (!!) and somehow even he does not grasp the problem we (and you
            apparently) are struggling with. By now, there is a different Product
            Manager to whom I have promised a report that explains (hopefully
            clearly) the problem but also the concepts for a solution (that can be
            used to define an implementation in UCM).

            But I am still struggling with finding a solving concept when doing
            component development and product release development simultaneuously
            in the SAME project. I know how to do it when separating component
            development projects from product release integration projects (even
            then composite baselines are not helpful).

            So, can you elaborate a bit on the direction you think UCM should go into?

            Regards,
            Frank.

            TOPIC Software Group
            P.O. box 440, NL-5680 AK Best
            Netherlands
            Telefoon (+31) - 499 - 33.69.77
            Telefax (+31) - 499 - 33.69.78
            <============================================================
            To unsubscribe, send email to
            majordomo@lists.us.ibm.com and put these words in the
            message body: unsubscribe cciug
            ============================================================>
            • SystemAdmin
              SystemAdmin
              47293 Posts
              ACCEPTED ANSWER

              Re: Re:Re: Re:Composite-baselines and their components

              ‏2004-12-10T08:54:43Z  in response to SystemAdmin
              Hi Frank,

              The direction I think UCM should go into is oh so simple.

              " Any non-modifiable component shall not be modified, unless it is explicitly declared modifiable by the user. "

              That's it.

              What I have proposed to two different Product Managers (one being 'R.C', the latter is 'K.S') is to not change anything: if ClearCase want, for technical internal reason, produce baseline on non-modifiable component, so be it.
              But the user should not be bothered with them in any way. Those baselines should stay invisible.

              Why Component dependency matters ?
              Two words:
              Release Management.

              To make an UCM project and establishing a configuration (for development, assembly or integration purpose of a bunch of components) has one goal: release the product.
              In order to control what we release, ClearCase proposes since last 2001 (and CC2002) baseline dependencies, with the detection of override and overriden baselines, in order to warn the user of potential problems due to overlapping baseline dependencies.
              But that crucial feature (since 'release' is, in the end, what it is all about), is not working.

              I am up to 60 emails, 3 conferences calls, 2 articles reviews over 20 months period.

              The whitepaper on composite baseline is on http://www-106.ibm.com/developerworks/rational/library/5134.html

              It has been submitted to me for review in april. Every comments I made have been ignored.
              That whitepaper has been published in june, but is not referenced by developerworks (you can not 'search' it... and is not seen anywhere in http://www-106.ibm.com/developerworks/views/rational/articles.jsp or http://publib-b.boulder.ibm.com/cgi-bin/searchsite.cgi?Query=Rational&SearchMax=4999&SearchOrder=1&SearchFuzzy=FALSE)

              That whitepaper currently published on the web does not mention that:
              • release-oriented project does not scale well with the number of release components. That mean one can not espace for long to a component-oriented project organisation;
              • baselines created on a non-modifiable composite baseline are only usefull for ClearCase, not for the user;
              • section 'Creating Composite Baselines' is USELESS: The user can not begin to make composite baselines with regular root-based component without being stopped at one point or another with the impossibility to remove or rebase sideways... which means composite baselines with rootless component is the only way to go;
              • reverting or removing a composite baseline based on non-modifiable rootless component with parasite baselines on it is... impossible!;
              • those parasite baselines lead to "baseline cluttering", which makes a "browse baseline" useless and implies serious performance issues (when one want to rebase and have to wait x minutes in order to the huge list of baselines to display itself). Rendering those parasite baselines obsolete is not the correct solution.

              If anyone is interested in the 'reviewed' version of that whitepaper, I can email it to him.

              Best regards,

              daniel.chaffiol@sgcib.com
              • SystemAdmin
                SystemAdmin
                47293 Posts
                ACCEPTED ANSWER

                Re:Re: Re:Re: Re:Composite-baselines and their components

                ‏2004-12-10T22:51:37Z  in response to SystemAdmin
                > What I have proposed to two different Product Managers (one being 'R.C', the latter is 'K.S') is to not change anything: if ClearCase want, for technical internal reason, produce baseline on non-modifiable component, so be it.

                Yes, I know them well.

                > I am up to 60 emails, 3 conferences calls, 2 articles reviews over 20 months period.

                Hmm... a bit more then I did. I spoke with R.C. about composite
                baselines at the RUC 2001 and how the concept did not work. Not only
                for release management, by the way.

                > The whitepaper on composite baseline is on http://www-106.ibm.com/developerworks/rational/library/5134.html

                Thanks. I saw it but did not read it carefully yet. But from the
                explanation I got back in 2001 (at the RUC), I was not convinced.

                > That whitepaper has been published in june, but is not referenced by developerworks

                Yes, I noticed.

                > That whitepaper currently published on the web does not mention that:
                > * release-oriented project does not scale well with the number of release components. That mean one can not espace for long to a component-oriented project organisation;

                I am involved with 3 customers doing (or trying to do)
                component-oriented development with UCM. For each of them, I have
                recommended not to use composite baselines. One of them tried and
                found out themselves that it is not good.

                > * baselines created on a non-modifiable composite baseline are only usefull for ClearCase, not for the user;

                Pffff... baselines for non-modifiable components. Bad idea anyway.

                > * section 'Creating Composite Baselines' is USELESS: The user can not begin to make composite baselines with regular root-based component without being stopped at one point or another with the impossibility to remove or rebase sideways... which means composite baselines with rootless component is the only way to go;

                I have not been able to pinpoint why, but I do agree with you.

                > * those parasite baselines lead to "baseline cluttering", which makes a "browse baseline" useless and implies serious performance issues (when one want to rebase and have to wait x minutes in order to the huge list of baselines to display itself). Rendering those parasite baselines obsolete is not the correct solution.

                Large baselines lists have been a problem for a long time. 2003.06 has
                some improvement by not trying to select ALL baselines, but only for
                one component at the time. Still, with thousands of baselines it is
                slow.
                > If anyone is interested in the 'reviewed' version of that whitepaper, I can email it to him.

                YES, please!
                frankschophuizen at yahoo dot com or
                fschophuizen at gmail dot com

                Thanks so much!!

                Frank.
                TOPIC Software Group
                P.O. box 440, NL-5680 AK Best
                Netherlands
                Telefoon (+31) - 499 - 33.69.77
                Telefax (+31) - 499 - 33.69.78
                <============================================================
                To unsubscribe, send email to
                majordomo@lists.us.ibm.com and put these words in the
                message body: unsubscribe cciug
                ============================================================>
                • SystemAdmin
                  SystemAdmin
                  47293 Posts
                  ACCEPTED ANSWER

                  Re: Re:Re: Re:Re: Re:Composite-baselines and their components

                  ‏2004-12-13T09:27:53Z  in response to SystemAdmin
                  Hi Frank,

                  For whoever might be interested, the whitepaper I was referring in my previous post about baseline composite (Best practices for using composite baselines in UCM , http://www-136.ibm.com/developerworks/rational/library/5134.html) is actually referenced in the developerworks section:
                  http://www-128.ibm.com/developerworks//rational/library/showmore/56-m.html

                  ... Yes, it is in the 'ClearQuest library' section! And I know why: That document was originally a "Microsoft Word" document about "IBM Rational ClearQuest performance improvement" (same author). The first draft I had of the new whitepaper had still a title referring to this previous study.
                  Not only this ClearCase UCM whitepaper has not been "officially" published, but it has been under the wrong section. Go Figure.
                  I have sent you the reviewed version of that whitepaper.

                  For the record, I am involved with more than twenty component-oriented UCM projects. Composite Baselines are used, but only with rootless component, and only with a one-depth level.
                  Composite Baselines are still usefull for:
                  - development projects where a composite component keeps track of baselines on other writable components (we have separated a 'development' component where developpers have any kind of files and organisation, and a 'distrb' component', with a normalized packaging of files)
                  - integration projects (for homologation, pre-prod or production purpose) where a 'global' rootless component keeps tracks of a collection of baselines representing the set of components tested or deployed within a given UCM environment.
                  - referential projects (for keeping track of a collection of technical libraries, for instance we have a global rootless component LIB_EXT referencing more than 50 libraries apache, bea, oracle, sourceforge, sun, ...)

                  To try to use component dependency with more than one level is:
                  - doomed for root-based components, since the parasite baselines will prevent the user to do anything with that composite root-based baseline (no rebase forward, no revert, no remove, only solution, create a new UCM project with the correct baseline)
                  - limited for rootless components (no revert, no remove, rebase forward only)
                  - dangerous since it will trigger a massive number of new baselines with performance problems...

                  The consequence is any development, patch or refactoring project can not use a 'global' label (a composite baseline referencing a list of dependent baselines), since it will be stuck with that baseline if the user introduce any kind of overlapping dependency.
                  And that is a shame, since rebasing one composite baseline (including within it 150 other baselines) is very quick in CC2003 (less than 30 seconds). Whereas rebasing 150 baselines (in one cleartool command line) on a stream takes up to 10 minutes...

                  Composite baseline is a terrific idea. Its implementation is terrible.

                  daniel.chaffiol@sgcib.com
                  • SystemAdmin
                    SystemAdmin
                    47293 Posts
                    ACCEPTED ANSWER

                    Re: Re:Re: Re:Re: Re:Composite-baselines and their components

                    ‏2005-01-06T11:32:36Z  in response to SystemAdmin
                    Hi all,

                    Thanks to Ken, I discovered yesterday a second Rational/IBM document which covers (amongst other things) the problem of component dependencies:
                    The redbook "Software Configuration Management: A Clear Case for IBM Rational ClearCase and ClearQuest UCM" available at http://www.redbooks.ibm.com/abstracts/SG246399.html and published last december, 15th.

                    However, I am sad (and a little shocked as well) to report that this redbook does refer to the misleading whitepaper "Best practices for using composite baselines in UCM" (http://www-136.ibm.com/developerworks/rational/library/5134.html) without ever mentionning the difficulties related with parasite baselines preventing any rebase possiblity.
                    Hence their section "Managing complexity" (chapter 11, page 211) is equally misleading, since it insists upon the utilisation of composite baselines without ever mentionning the downfall of that approch (the downfall is: for a component-oriented project, it just does not work)

                    Plus, they recommand the "flatten" approach": list your dependencies within one level of a rootless component dependency, which greatly diminishes the interest of dependencies (where you can see what baseline is overriden, what baseline overrides), and which solves nothing (you will not be able to import that composite baseline in another UCM project without exposing yourself to new overlapping scenario, and to new parasite baselines)

                    Do not get me wrong, this redbook is still a "must-read", does a good job to cover all UCM issues... and does even acknowledge some of its current limitations, like the lack of component refactoring, page 170.

                    However, their presentation of composite baselines seems rather far of a general presentation, and looks more like a cover-up of a major missing feature (release management) through the complete failure of the use of component dependencies.
                    They only mention page 231 "Using rootless components enables you to circumvent the limitations of using composite baselines", and make a vague allusion to performance problems page 230... leaving a lot of other "limitations" in the shadows.

                    Still hope remains, and I am convinced that the ClearCase development team will move forward in the right direction :) (even if some might think otherwise, see http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=7985211&cat=24&thread=69267&forum=333#7985211 !)

                    In that spirit, I wish them and all of you an happy new year ;)

                    daniel.chaffiol@sgcib.com
              • SystemAdmin
                SystemAdmin
                47293 Posts
                ACCEPTED ANSWER

                RE:Re: Re:Re: Re:Composite-baselines and their components

                ‏2004-12-10T23:06:52Z  in response to SystemAdmin
                I'd like a copy please!

                Dpeugeot at digitalmotorworks dot com

                Thanks
                Deanna

                -----Original Message-----
                From: owner-cciug@lists.us.ibm.com mailto:owner-cciug@lists.us.ibm.com On
                Behalf Of sgidea
                Sent: Friday, December 10, 2004 2:55 AM
                To: cciug@lists.us.ibm.com
                Subject: cciug Re: Re:Re: Re:Composite-baselines and their components

                Hi Frank,

                The direction I think UCM should go into is oh so simple.

                " Any non-modifiable component shall not be modified, unless it is
                explicitly declared modifiable by the user. "

                That's it.

                What I have proposed to two different Product Managers (one being 'R.C', the
                latter is 'K.S') is to not change anything: if ClearCase want, for
                technical internal reason, produce baseline on non-modifiable component, so
                be it.
                But the user should not be bothered with them in any way. Those baselines
                should stay invisible.

                Why Component dependency matters ?
                Two words:
                Release Management.

                To make an UCM project and establishing a configuration (for development,
                assembly or integration purpose of a bunch of components) has one goal:
                release the product.
                In order to control what we release, ClearCase proposes since last 2001 (and
                CC2002) baseline dependencies, with the detection of override and overriden
                baselines, in order to warn the user of potential problems due to
                overlapping baseline dependencies.
                But that crucial feature (since 'release' is, in the end, what it is all
                about), is not working.

                I am up to 60 emails, 3 conferences calls, 2 articles reviews over 20 months
                period.

                The whitepaper on composite baseline is on
                http://www-106.ibm.com/developerworks/rational/library/5134.html

                It has been submitted to me for review in april. Every comments I made have
                been ignored.
                That whitepaper has been published in june, but is not referenced by
                developerworks (you can not 'search' it... and is not seen anywhere in
                http://www-106.ibm.com/developerworks/views/rational/articles.jsp or
                http://publib-b.boulder.ibm.com/cgi-bin/searchsite.cgi?Query=Rational&Search
                Max=4999&SearchOrder=1&SearchFuzzy=FALSE)

                That whitepaper currently published on the web does not mention that:
                • release-oriented project does not scale well with the number of release
                components. That mean one can not espace for long to a component-oriented
                project organisation;
                • baselines created on a non-modifiable composite baseline are only usefull
                for ClearCase, not for the user;
                • section 'Creating Composite Baselines' is USELESS: The user can not begin
                to make composite baselines with regular root-based component without being
                stopped at one point or another with the impossibility to remove or rebase
                sideways... which means composite baselines with rootless component is the
                only way to go;
                • reverting or removing a composite baseline based on non-modifiable
                rootless component with parasite baselines on it is... impossible!;
                • those parasite baselines lead to "baseline cluttering", which makes a
                "browse baseline" useless and implies serious performance issues (when one
                want to rebase and have to wait x minutes in order to the huge list of
                baselines to display itself). Rendering those parasite baselines obsolete is
                not the correct solution.

                If anyone is interested in the 'reviewed' version of that whitepaper, I can
                email it to him.

                Best regards,

                daniel.chaffiol@sgcib.com
                <============================================================
                To unsubscribe, send email to
                majordomo@lists.us.ibm.com and put these words in the
                message body: unsubscribe cciug
                ============================================================>
                <============================================================
                To unsubscribe, send email to
                majordomo@lists.us.ibm.com and put these words in the
                message body: unsubscribe cciug
                ============================================================>
              • SystemAdmin
                SystemAdmin
                47293 Posts
                ACCEPTED ANSWER

                Re: Re:Re: Re:Composite-baselines and their components

                ‏2005-01-18T11:27:41Z  in response to SystemAdmin
                Hi all,

                Reminder: this thread exposes the inconsistency and incoherency of UCM when it comes to component dependency management (a huge issue related to release management in a component-oriented environment such as one described in Rational/IBM UCM redbook http://www.redbooks.ibm.com/redbooks/SG246399/20-15.htm)
                The incoherency and inconsistency are based on a simple fact:

                "Non-Modifiable components can be modified by ClearCase"

                Previous messages within this thread have already given scenarios where that happens, and why it is very unfortunate for the user (no added value, only pain..)
                Thanks to Benoit Salaun, a ClearCase administrator that recently join the same company where I work, here is a new scenario where a non-modifiable component is modified.

                P1 (project UCM P1)
                S1 (Stream S1 of P1, does not matter if it is integration or development stream)
                ...nrA1w (modifiable rootless component nrA)
                ...rB1 (baseline rB1 or a non-modifiable rootbased component B)
                ...rC2 (baseline rC2 or a non-modifiable rootbased component C)
                ...rD3 (baseline rD3 or a non-modifiable rootbased component D)

                Goal:
                Set-up a one-level dependency between modifiable rootless component A, and non-modifiable components B, C and D, in order to memorize the list of the B, C and D baselines within one global 'pure composite baseline' of A.
                ('pure composite baseline' is defined in UCM redbook here: http://www.redbooks.ibm.com/redbooks/SG246399/20-21.htm)

                Process:
                Through the GUI, you open 'edit baseline dependencies' (ClearCase 2003 SR3, Windows XpSP1)
                You drag and drop B under A, then C under A, then... oups... D under B!
                Your mistake, you instantly delete D under B, then resume your drag-and-drop of D under A.
                Then, as asked by the GUI, you enter the name of your global composite baseline A. MY_GLOBAL_BASELINE1.0.0

                Guess what ?

                A baseline MY_GLOBAL_BASELINE1.0.0 is created on A (so far so good)
                Another baseline (same title MY_GLOBAL_BASELINE1.0.0) is created on B on stream S1 !?
                Difference between that new baseline of B compared with legacy baseline rB1 ? None whatsoever.
                Interest of that baseline ? None whatesoever.
                Effect on the user ? Utter confusion, call from the user asking why, when he browses the baselines of his component B, a 'MY_GLOBAL_BASELINE1.0.0' is displayed on a stream he never heard of.

                The problem is not so on the GUI part: the creation of the extra baseline (even if the user reverts immediatly his action) look like a simple defect. A PMR has been opened, may be a RFE will be created...
                The real problem lies in the creation of a baseline (for any reason) on a non-modifiable component. That has all kind of nasty side-effects, including this blunder being possible...

                UCM is still a very valuable process, but its persistent inhability to properly manage dependencies of components in a world of 'componentization' is worriesome.
                Hopefully, future contacts with UCM development team are scheduled and will allow all of us (clients as well as Rational/IBM) to move forward.
                Benoit and I will keep you posted.

                PS: by the way, Benoit Salaun is a name that can rings a bell for some of you. He has spent 4 years at Rational support Netherland ;) He is now on the other side of the fence,... and is discovering the "dark side of the force 'UCM'" :)
              • SystemAdmin
                SystemAdmin
                47293 Posts
                ACCEPTED ANSWER

                Re: Re:Re: Re:Composite-baselines and their components

                ‏2005-01-20T14:43:04Z  in response to SystemAdmin
                Hi all,

                For those who are still following this thread, you may be asking yourself what is the primary cause of that component management dependency failure, triggering parasite baseline.
                (Reminder: those unwanted baselines will cause the user to be stuck with baseline on read-only component, plus they will be created in great number causing performance issue)

                Let's take a closer look to the cardinal scenario of parasite baseline, the overlapping dependency hierarchy:

                P1 (project UCM P1)
                S1 (Stream S1 of P1, does not matter if it is integration or development stream)
                ...nrA1w (composite baseline A1 modifiable rootless component nrA)
                ... --rB1 (A1 includes within its dependencies baseline rB1 of a NON-modifiable rootbased component B) <overriden>
                ...rB2 (baseline rB2 of a NON-modifiable rootbased component B) <override>

                What you have here is a overlapping dependency hierarchy.

                You also have a component dependency hierarchy (when you make 'edit baseline dependencies' on the stream S1), which reflect the baseline situation:
                nrA
                ..rB (component nrA depends on rootbased component B)
                rB

                Now you make a baseline on the stream S1 (without having made any checkout/checkin)

                That baseline is created on component nrA in order to record the fact that the baseline of nrA used into this projects does not import rB1 but actually rB2.
                and... this is CORRECT
                The composite baseline produced on nrA rightfully records the change of one of its dependent baselines due to an override.
                Fine.

                Except (=> bug1) that if you take that very same project but without any modifiable components... a baseline will still be produced on nrA! Whereas, off course, no baseline should be ever produced: the only UCM object concerned with the overlap of dependency is the stream S1.
                With that (now parasite) extra baseline, you won't be able anymore to rebase or remove nrA from your project. You will be stuck with nrA1.

                Now you take that 'overlapping dependency hierarchy' scenario one step further (and one level deeper)

                P1 (project UCM P1)
                S1 (Stream S1 of P1, does not matter if it is integration or development stream)
                ...nrD1w (composite baseline D1 modifiable rootless component nrA)
                ...--nrA1 (D1 includes within its dependencies composite baseline nrA1 of a NON-modifiable rootless component A)
                ... --rB1 (baseline B1 NON-modifiable rootbased component rB) <overriden>
                ...rB2 (baseline rB2 of a NON-modifiable rootbased component B) <override>

                Here one fundation baseline overrides a depth-2 baseline.

                The component dependency hierarchy looks like :
                nrD
                ..nrA (nrD depends on rootless component nrA)
                ....rB (nrA depends on rootbased component B)
                rB
                When you make a baseline 'MY_BL' on stream S (without having made any checkout/checkin), where do you thing a new baseline will be created ?

                A parasite baseline 'MY_BL.nrA' will be produced, like in the previous scenario, on nrA (which is non-modifiable) to record the use of rB2 instead of rB1
                A legitimated baseline will be produced on nrD (which is modifiable) to record the use of 'MY_BL.nrA' instead of nrA1...

                Now ask yourself: which composite baseline should have detected and recorded the change of dependency, that is the use of rB2 instead of rB1 ?
                The non-modifiable component nrA ?
                Or the composite baseline of the modifiable component nrD ?

                The developpers choose to repeat the algorithm of the first scenario (the one with one-level depth component dependency): they look for the parent of an overriden baseline and produce a baseline on it...(=> bug2) even if that parent is a non-modifiable component.
                Then they produced a new baseline on nrD to record the previous new parasite baseline!
                Which is plain wrong.
                You will not be able to add to your fundation baselines another version of nrA baseline, because clearcase will claim that you have made modification on nrA!?

                My guess is they believe that to record rB2 within nrD would be incoherent with the component dependency hierarchy, because it would give something like:

                nrD
                ..nrA (nrD depends on rootless component nrA)
                ....rB (nrA depends on rootbased component B)
                ..rb (nrD depends also on rootbased component B)
                rB

                BUT:
                1/ this is not false: in this overlapping dependency situation, nrD does uses directly a baseline of nrB
                2/ that dependency diagram is strictly equivalent to the initial dependency modelisation
                nrD
                ..nrA (nrD depends on rootless component nrA)
                ....rB (nrA depends on rootbased component B)

                I believe one of the primary cause of all that mess is the will to repect the component dependency modelisation (the tree you see when you do an 'edit baseline dependencies' on a stream).
                The other primary cause is unknown...:
                • you start to modify non-modifiable stuff ?
                • you make a whitepaper on "Best practices for using composite baselines in UCM" without any warning about the side-effects ??
                • you ask a chump to review that article, to criticized it, then you ignore each and every comments he makes and you publish it ???
                • you published it in the ClearQuest library section of developerWorks ????
                • you write a redbook (quite interresting actually) without refering the whitepaper in the "composite baseline" section ?????
                Man, this looks like a baaad trip.

                Anyway, the correct solution is to record only one new baseline within a composite baseline of a modifiable component (here nrD, not nrA). Plus you avoid the creation of another useless baseline.
                If there is no modifiable component, the correct solution is too record nothing on the component level. The stream will keep the override/overriden information.

                I rest my case.
                daniel.chaffiol@sgcib.com
                • SystemAdmin
                  SystemAdmin
                  47293 Posts
                  ACCEPTED ANSWER

                  Re: Re:Re: Re:Composite-baselines and their components

                  ‏2006-03-21T22:40:48Z  in response to SystemAdmin
                  Just checking if this issue has been resolved, if so any information on the fix version or patch available would be appreciated.
                  • JirongHu
                    JirongHu
                    680 Posts
                    ACCEPTED ANSWER

                    Re: Re:Re: Re:Composite-baselines and their components

                    ‏2006-03-22T20:52:05Z  in response to SystemAdmin
                    I am more interested in how to fix the problem with all these "parasite baselines" in my environment.

                    Jirong
                  • SystemAdmin
                    SystemAdmin
                    47293 Posts
                    ACCEPTED ANSWER

                    Re: Re:Re: Re:Composite-baselines and their components

                    ‏2006-03-23T13:00:01Z  in response to SystemAdmin
                    Hi,

                    Please find a recent (march 2006) follow-up to this historical thread in:
                    [ the thread on developerworks]

                    To summarize:
                    * no fix, only a workaround (use only rootless components), which solves nothing as it creates parasite baselines on those rootless components - parasite baselines which do not make any sense to the user -.
                    * according to the ClearCase developers' point of view, this issue is fixed on the incorrect belief that an overlap dependency case implies the modification of the overriden dependency hierarchy (hence the creation of the parasite baseline)
                    * we are continuously working on explaining the side-effects of this behaviour with support and ClearCase developers, and argue that no relationship should be modified. An overlap hierarchy takes place only in the context of a stream. Each 'relationship' (dependency hierarchy) taken individually should retain its identity. Only the stream should record or compute any overriden/override information.
                    • SystemAdmin
                      SystemAdmin
                      47293 Posts
                      ACCEPTED ANSWER

                      Re: Re:Re: Re:Composite-baselines and their components

                      ‏2006-04-26T06:41:59Z  in response to SystemAdmin
                      Hello,

                      yesterday I was searching for comments to the issue "override/overridden entries". So I came across to this thread and was alarmed about the potential trouble we could get into.

                      Today in the morning I changed a test project with a composite baseline in the project by appending a baseline from a read-only component (let´s call this component 'roComp'). Then I changed this baseline creating the override/overridden entry. I created a new baseline in the integration stream (without any activities included in the baseline). Just one baseline was created: in the composite component. Then I rebased the integration stream to a former baseline of roComp and succeeded. I took a new baseline, again only in the composite component appeared a new baseline, and delivered it to mainline (where I had to change the properties of roComp to modifiable, as Frank somewhere suggested; additional I had to change some deliver policies). Now a new baseline is created in component roComp too (because I changed it to modifiable before delivery).

                      Either I tested the wrong scenario or IBM has fixed this problem. Can anyone test it with SR5 and give me a feedback? Otherwise I will have to create a trigger preventing ClearCase from creating baselines in read-only components.

                      Our ClearCase version:

                      C:\>cleartool -verall
                      ClearCase version 2003.06.00 (Fri Apr 18 13:06:18 2003)
                      clearcase patch p2003.06.01 (Fri Sep 5 11:59:28 2003)
                      clearcase patch p2003.06.12 (Fri Nov 7 11:59:28 2003)
                      clearcase patch p2003.06.14 (Fri Oct 8 11:59:28 2004)
                      clearcase patch p2003.06.15 (Fri Apr 9 11:59:28 2005)
                      clearcase patch p2003.06.16 (Fri Jul 1 11:59:28 2005)
                      @(#) MVFS version 2003.06.10+ (Thu Jan 27 04:26:46 2005)
                      cleartool 2003.06.10+ (Fri Jun 3 21:18:43 2005)
                      libatriaadm 2003.06.10+ (Tue May 17 12:47:41 2005)
                      libatriaccfs 2003.06.10 (Thu May 22 02:26:37 2003)
                      libatriaclient_meters 2003.06.10+ (Fri May 6 21:17:46 2005)
                      libatriacm 2003.06.10+ (Tue May 17 12:48:05 2005)
                      libatriacmd 2003.06.10+ (Fri Jun 3 20:47:01 2005)
                      libatriacmdsyn 2003.06.10+ (Tue May 17 12:51:41 2005)
                      libatriacredmap 2003.06.10+ (Wed Jun 23 07:43:55 2004)
                      libatriadbrpc 2003.06.10+ (Fri May 6 20:56:38 2005)
                      libatriaks 2003.06.10+ (Fri May 6 20:49:32 2005)
                      libatriamntrpc 2003.06.10+ (Tue May 17 12:51:59 2005)
                      libatriamsadm 2003.06.10+ (Fri May 6 20:49:08 2005)
                      libatriamvfs 2003.06.10 (Sat Apr 12 20:49:57 2003)
                      libatriasplit 2003.06.10+ (Tue May 17 12:49:52 2005)
                      libatriasum 2003.06.10+ (Wed May 18 20:46:50 2005)
                      libatriasumcmd 2003.06.10+ (Wed May 18 20:47:39 2005)
                      libatriatbs 2003.06.10+ (Fri May 6 20:50:15 2005)
                      libatriatool 2003.06.10+ (Tue May 17 12:49:47 2005)
                      libatriaview 2003.06.10+ (Tue May 17 12:49:34 2005)
                      libatriavob 2003.06.10+ (Tue May 17 12:48:25 2005)
                      libatriaxdr 2003.06.10+ (Fri May 6 20:51:57 2005)
                      db_server 2003.06.10+ (Fri May 6 22:12:48 2005)
                      VOB database schema version: 54

                      Many thanks and best regards,

                      gj
                      • SystemAdmin
                        SystemAdmin
                        47293 Posts
                        ACCEPTED ANSWER

                        Re: Re:Re: Re:Composite-baselines and their components

                        ‏2006-04-27T09:27:14Z  in response to SystemAdmin
                        Hello,

                        Indeed you did not test the right scenario...
                        Parasite baselines do appear when using dependencies over more than one level deep.

                        You'll find detailed information in this thread: http://www.cmcrossroads.com/ubbthreads/showthreaded.php?Cat=&Number=62994&page=&view=&sb=5&o=&vc=1 .
                        The second part of the article refers to rootless composite baselines, while the first part explains rooted composite baselines.

                        Rgs
  • SystemAdmin
    SystemAdmin
    47293 Posts
    ACCEPTED ANSWER

    Re: Composite-baselines and their components

    ‏2006-04-26T20:59:43Z  in response to SystemAdmin
    Happened to verify the parasite baseline scenario on a windows test PC running CC p2003.06.16(SR5), in a composite baseline consisting of modifiable and readonly root component vobs. If I do apply a baseline on the rootless vob, the baseline is applied only on the modifiable root component and not on the readonly root component, looks to be positive sign. Any feedback from the experts would be greatly appreciated.

    Thanks
    • SystemAdmin
      SystemAdmin
      47293 Posts
      ACCEPTED ANSWER

      Re: Composite-baselines and their components

      ‏2006-04-27T09:41:46Z  in response to SystemAdmin
      Hi,

      I tested 2003SR5 on the parasite baseline scenario and found the problem remains. - Make sure you use a 2-level deep dependency -

      Find more details on this thread http://www.cmcrossroads.com/ubbthreads/showthreaded.php?Cat=&Number=62994&page=&view=&sb=5&o=&vc=1

      Since Rational does not consider this as a bug, i dont think we'll see it fixed soon, sadly ...

      Rgs
      • saran2
        saran2
        28 Posts
        ACCEPTED ANSWER

        Re: Composite-baselines and their components

        ‏2007-10-15T21:21:48Z  in response to SystemAdmin
        Hi All,

        Is the issue resolved in 7.0.. 7.0.0.1 , 7.0.1 or still it remains etc?

        please let me know?

        Thanks
        Saran
        • SystemAdmin
          SystemAdmin
          47293 Posts
          ACCEPTED ANSWER

          Re: Composite-baselines and their components

          ‏2008-09-25T15:12:22Z  in response to saran2
          Hi all,

          I wonder if "parasite" baselines are still a problem in ClearCase 7.1?
          Parasite baseline: a baseline of a composite baseline, created on a non-modifiable component

          See also ClearCase wiki:
          http://www.ibm.com/developerworks/wikis/display/cm/How+to+work+with+root-less+components

          Frank.

          TOPIC Embedded Systems
          Best, the Netherlands
          • JirongHu
            JirongHu
            680 Posts
            ACCEPTED ANSWER

            Re: Composite-baselines and their components

            ‏2008-09-26T20:33:58Z  in response to SystemAdmin
            I am also interested in if anyone using a composite depends on another composite successfully. I've never tried that in a real project.

            Thanks.
            Jirong
            • jeff98air
              jeff98air
              817 Posts
              ACCEPTED ANSWER

              RE: [cciug] Re: Composite-baselines and their components

              ‏2008-09-26T21:41:30Z  in response to JirongHu
              Yes, it works fine, but you need to manage the members of the composites
              carefully. Since a stream can only select one baseline of a component
              at a time, if you have components that are a member of multiple
              composites, you can easily get into an "over-ridden baseline" situation.
              Sometimes, it's intentional, but most of the time, it's not.

              Composites of composites is commonly used when releasing suites of
              products and managing common collections of COTS products.

              -Jeff Ng

              -----Original Message-----
              I am also interested in if anyone using a composite depends on another
              composite successfully. I've never tried that in a real project.

              Thanks.
              Jirong
              _______________________________________________
              cciug mailing list
              cciug@lists.ca.ibm.com
              Unsubscribe:cciug-leave@lists.ca.ibm.com