Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

shared repository workspace

Hi,


Is it discouraged to use a shared repository workspace for different clients? Let's say I want to use that workspace from both Windows Shell (for documents) and IDz.

Regards,
Bernd.

0 votes


Accepted answer

Permanent link

You should never use a shared repo workspace for anything. A repository workspace must only ever be loaded by the user once. Concurrently working on the same components in the same repository workspace from different clients causes the repository workspace to go out of sync.

Streams are used to coordinate concurrent changes in the repository workspaces.

So if you plan to load the workspace completely, don't. If you can and want to only load it partially, you could, but I would argue it would be easier to have two repository workspaces for each system and fully load them.

Note that for personal builds the build user has only read permission and can not cause out of sync, so that is safe.

Bernd van Oostrum selected this answer as the correct answer

2 votes

Comments

What is the reason behind this limitation? It seems using different clients corrupts the metadata...


Thanks a lot for the confirmation, Ralph.

No, streams are used to allow concurrent changes in components in the repository workspaces  that flow to them. Although a repository workspace behaves almost as a stream it assumes changes either being done by a user and checked in or changes flow from streams.

It is not built to work with say a file being changed and checked in in a different client and now the state of the repository workspace and the loaded code (loaded in a different client) is different. All it allows to do is reload the component with the change that is out of sync. You could do that, but you won't be able to keep or merge changes you might have done to the same file or others in the component (in the other client).

It is really simple, if you think about it.

1 vote

 The limitation is for improving performance.   If each sandbox for a given repository workspace kept track of all the information needed to efficiently deal with that repository workspace being modified by another client, then there would be a significant performance cost.   Instead, the sandbox implementation is optimized to assume it is very infrequent that some other client will modify that repository workspace (but it will notice, and then perform a usually expensive reconcile operation).   If the metadata is corrupted, that is a bug, and preferably you would report it so that it can be fixed (i.e. a sandbox will go out of sync if the workspace is modified by another client, but the metadata should not be corrupted).

1 vote

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,025

Question asked: Aug 22 '17, 4:10 a.m.

Question was seen: 2,725 times

Last updated: Sep 05 '17, 3:37 a.m.

Confirmation Cancel Confirm