Topic
  • 6 replies
  • Latest Post - ‏2013-09-12T00:38:56Z by brcowan
Ratan_k00
Ratan_k00
51 Posts

Pinned topic CCASE_DISABLE_FDN_REUSE variable

‏2013-01-11T06:56:47Z |
A new feature in CC 8.0:

A new ClearCase UCM environment variable, called CCASE_DISABLE_FDN_REUSE, has been added. When set to TRUE, this environment variable prevents the creation of duplicate baselines when a foundation baseline has already been reused in a previous "make baseline" operation and when the baseline that has been reused resides in a PVOB which is not under the same AdminVOB hierarchy as the PVOB where the new baseline is being created.

Will someone please explain clearly with an example why this env variable is required?
Updated on 2013-01-15T18:14:44Z at 2013-01-15T18:14:44Z by brcowan
  • brcowan
    brcowan
    733 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-01-11T13:51:35Z  
    ClearCase used to do some pretty exhaustive checks during the mkbaseline to go out of it's way to not create duplicate identical baselines in components. This is particularly true when creating composite baselines or when using a single mkbl command to create baselines in multiple components at the same time.

    In some cases shose checks would significantly slow down the mkbl operation. The current default is to skip some of these checks to improve mkbl speed. This environment variable reenables those checks.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
  • Ratan_k00
    Ratan_k00
    51 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-01-11T16:27:10Z  
    • brcowan
    • ‏2013-01-11T13:51:35Z
    ClearCase used to do some pretty exhaustive checks during the mkbaseline to go out of it's way to not create duplicate identical baselines in components. This is particularly true when creating composite baselines or when using a single mkbl command to create baselines in multiple components at the same time.

    In some cases shose checks would significantly slow down the mkbl operation. The current default is to skip some of these checks to improve mkbl speed. This environment variable reenables those checks.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
    Thanks for the response. Few questions:

    • If it speeds up then why not this be the default behavior for mkbl operation?

    • If we set env variable to TRUE always and create baselines, will there be any negative side effect later?

    • My setup:
    I have PVOB1 and PVOB2 and both the PVOBs are connected to a common ADMIN VOB. Comp1, Comp2 and rootless_comp1 are linked to PVOB1. Comp3, Comp4 and rootless_comp2 are linked to PVOB2. rootless_comp1 and rootless_comp2 are used to store composite baselines.
    Now I have a project proj_1 in PVOB1 and its configuration is comp1 basleine, comp2 baseline and a composite baseline from rootless_comp2.
    Now if I create a baseline on the int stream of proj1 then:
    -- if the env is not set: then mkbl operation creates baseline on int stream of comp3 and comp4 (because of rootless_comp2) even though it is not required
    -- if the env is set then it skips checking the rootless_comp2 composite baseline and just creates a baeline on comp1 and comp2 and one composite basleine in rootless_comp1.

    Is this my understanding correct?

    Please let me know.

    Thanks!
  • brcowan
    brcowan
    733 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-01-11T18:34:37Z  
    • Ratan_k00
    • ‏2013-01-11T16:27:10Z
    Thanks for the response. Few questions:

    • If it speeds up then why not this be the default behavior for mkbl operation?

    • If we set env variable to TRUE always and create baselines, will there be any negative side effect later?

    • My setup:
    I have PVOB1 and PVOB2 and both the PVOBs are connected to a common ADMIN VOB. Comp1, Comp2 and rootless_comp1 are linked to PVOB1. Comp3, Comp4 and rootless_comp2 are linked to PVOB2. rootless_comp1 and rootless_comp2 are used to store composite baselines.
    Now I have a project proj_1 in PVOB1 and its configuration is comp1 basleine, comp2 baseline and a composite baseline from rootless_comp2.
    Now if I create a baseline on the int stream of proj1 then:
    -- if the env is not set: then mkbl operation creates baseline on int stream of comp3 and comp4 (because of rootless_comp2) even though it is not required
    -- if the env is set then it skips checking the rootless_comp2 composite baseline and just creates a baeline on comp1 and comp2 and one composite basleine in rootless_comp1.

    Is this my understanding correct?

    Please let me know.

    Thanks!
    The speedup (no EV set, or set to FALSE) is the default behavior. Without the EV, mkbl does not execute some old validation code. As as result mkbl is:
    - faster, possibly MUCH faster,
    - is more likely to create a baseline that has no changes from it's predecessor baseline

    With the EV set to TRUE, mkbl once again exhaustively validates the baseline tree of the components you are creating baselines in. So, it:
    - can be a lot slower depending on the baseline tree (or trees, if you imported a lot of labels as baselines) of each component.
    - will be a lot more conscientious about creating baselines with no changes from their predecessors.

    So, with the EV not set, a mkbl on multiple components (or a composite, which is always across multiple components) is more likely but not guaranteed to create "extra" baseline objects. With it set to TRUE mkbl is much less likely to create the "extra" baselines.

    It became a case of "What is the operational impact of this extra baseline object?" (Nearly none) versus "What is the operational impact of the mkbl operation taking 30 minutes?" Performance won.

    An extra baseline or 2 in a component is usually not that big a deal. But having developers, integrators, project managers, etc., lose that big a chunk of their work days was and is.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
  • Ratan_k00
    Ratan_k00
    51 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-01-15T03:37:07Z  
    • brcowan
    • ‏2013-01-11T18:34:37Z
    The speedup (no EV set, or set to FALSE) is the default behavior. Without the EV, mkbl does not execute some old validation code. As as result mkbl is:
    - faster, possibly MUCH faster,
    - is more likely to create a baseline that has no changes from it's predecessor baseline

    With the EV set to TRUE, mkbl once again exhaustively validates the baseline tree of the components you are creating baselines in. So, it:
    - can be a lot slower depending on the baseline tree (or trees, if you imported a lot of labels as baselines) of each component.
    - will be a lot more conscientious about creating baselines with no changes from their predecessors.

    So, with the EV not set, a mkbl on multiple components (or a composite, which is always across multiple components) is more likely but not guaranteed to create "extra" baseline objects. With it set to TRUE mkbl is much less likely to create the "extra" baselines.

    It became a case of "What is the operational impact of this extra baseline object?" (Nearly none) versus "What is the operational impact of the mkbl operation taking 30 minutes?" Performance won.

    An extra baseline or 2 in a component is usually not that big a deal. But having developers, integrators, project managers, etc., lose that big a chunk of their work days was and is.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
    Hi Brian,

    Thanks for the response. As per your tech note:


    A new ClearCase UCM environment variable, called CCASE_DISABLE_FDN_REUSE, has been added. When set to TRUE, this environment variable prevents the creation of duplicate baselines when a foundation baseline has already been reused in a previous "make baseline" operation and when the baseline that has been reused resides in a PVOB which is not under the same AdminVOB hierarchy as the PVOB where the new baseline is being created.

    So, if setting this EV to FALSE (or not set) makes mkbl operation faster, then why and when should we set ENV to TRUE? I was underthe impression that setting this EV to TRUE makes the mkbl op faster.

    Thanks!
  • brcowan
    brcowan
    733 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-01-15T18:14:44Z  
    • Ratan_k00
    • ‏2013-01-15T03:37:07Z
    Hi Brian,

    Thanks for the response. As per your tech note:


    A new ClearCase UCM environment variable, called CCASE_DISABLE_FDN_REUSE, has been added. When set to TRUE, this environment variable prevents the creation of duplicate baselines when a foundation baseline has already been reused in a previous "make baseline" operation and when the baseline that has been reused resides in a PVOB which is not under the same AdminVOB hierarchy as the PVOB where the new baseline is being created.

    So, if setting this EV to FALSE (or not set) makes mkbl operation faster, then why and when should we set ENV to TRUE? I was underthe impression that setting this EV to TRUE makes the mkbl op faster.

    Thanks!
    This EV enables some old code to make extremely sure that we don't create any duplicate baselines. That old code takes longer to run. So, setting the EV to TRUE will slow down baseline creation, the extent of that slowdown depends on the complexity of your components' baseline trees.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/
  • brcowan
    brcowan
    733 Posts

    Re: CCASE_DISABLE_FDN_REUSE variable

    ‏2013-09-12T00:38:56Z  
    • brcowan
    • ‏2013-01-15T18:14:44Z
    This EV enables some old code to make extremely sure that we don't create any duplicate baselines. That old code takes longer to run. So, setting the EV to TRUE will slow down baseline creation, the extent of that slowdown depends on the complexity of your components' baseline trees.

    =================================================================
    Brian Cowan
    Advisory Software Engineer
    ClearCase Software Advisory Team (SWAT)
    Rational Software
    IBM Software Group
    550 King St
    Littleton, MA 01460

    Phone: 1.978.899.5436
    Web: http://www.ibm.com/software/rational/support/

    Apparently, I read the defect/RFE on this issue backwards.

    The variable disables some code that is designed to prevent duplicate baseline creation.  Setting this variable to TRUE will speed baseline creation, but may create a new composite baseline that, in some rare conditions, has the same member baselines as the streams current foundation baseline in that same rootless component.

    In these cases where the "duplicate" baseline was observed:

    1. It occurred in an environment where composite baselines contained other composite baselines, and was at least one level below the top-level composite baseline.
    2. it required:
      • Manually overriding a baseline referenced in the composite hierarchy,
      • Creating a new set of baselines was created while the override was in place, and
      • Later removing the override
    3. The duplicates truly reflect the stream's configuration, but hide the fact that the stream has "no net change" in that subtree of its configuration, as compared to its current foundation.