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

[JensN.]

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

[mrump]

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

[kthierer]

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