Skip to main content
J
JensN.1-Visitor
1-Visitor
February 21, 2014
Question

[SI] freezing shared members vs. shared build projects?

  • February 21, 2014
  • 1 reply
  • 1665 views

Hi @all,

for a member: is freezing a shared member exactly the same as sharing a project with this member as shared build? Normally, if we want to have some data shared into another project in "read-only"-mode we would do this by sharing the subproject as shared build. But when we want to have shared only one member in this subproject, and other members would interfere with other members, should we do this by sharing just the member and freeze it afterwards?

Thanks, Jens

    1 reply

    M
    mrump16-Pearl
    16-Pearl
    February 21, 2014

    Hi Jens,

    I know you scenario well, so I here the differences If found so far :

    • shared subproject

    - definitely read only, no matter what permission the user has

    - there will be no "incomming change" visible in case there are newer revision available.

    • frozen shared member

    - the share is by default by-directional. so given the right permissions the user can checkin and create new revisions of the member (effecting the source of the share). The freeze only prevents the user from updating the member revision used in his (target) project.

    - in case there are newer revision available, this will be visible on the frozen share (might be confusing especially in IDEs)

    - as long as not specially defined the Freeze/Thaw permissions are inherited from the shared archives ACL. This might lead to very mixed ACLs in one project.

    HTH Matthias

      K
      kthierer12-Amethyst
      12-Amethyst
      August 24, 2016

      Just stumbled over this while searching for freezing issues

      >> - definitely read only, no matter what permission the user has

      unless he has knowledge and rights to configure subprojects

      Anyhow in my opinion configuring shared subprojects as build should

      be the default, to prevent overpopulating the projects history

      (and maybe driving the original author crazy).

      Build subprojects will not generate new project revisions for checkpoints

      coming from upper level projects.

      >> - there will be no "incomming change" visible in case there are newer revision available.

      didn't know this, thank you

      >> The freeze only prevents the user from updating the member revision

      didn't know this also, thank you

      (without deeply thinking about pros and cons I would judge this as a nasty behaviour)

      BTW:

      I discovered that you can have both: read only and visible changes

      - create a subproject include/project_shares.pj

      - add shared members (maybe at a specific revision)

      - checkpoint the subproject

      - configure the subproject to the revision created by the checkpoint

      If want to react to changes/updates you could:

      - configure the subproject to default

      - update member revisions as needed

      - checkpoint

      - configure the subproject to the revision created by the new checkpoint

      You can even have two subprojects in the same folder

        include/project_shares.pj (1.2)

        include/project.pj

      but some CLI commands get confused by this and two trees pointing to

      the same directory can cause a little confusion.

      Another thing I noticed abot freezes and checkpoints:

      As expected freezes are also included in checkpoints, but such difference

      (a member is frozen only on one of the checkpoints) will not be visible

      when comparing checkpoints (View Project Differences) with the gui.

      Since this is no content change probably no big deal, but good to know

      Thanks again for the new insights ,

           Jürgen

      Terms & ConditionsAccessibility statement