It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×12,005
×889
×56
×3

question asked: Aug 22 '17, 4:10 a.m.
question was seen: 2,581 times
last updated: Sep 05 '17, 3:37 a.m.

Related questions

shared repository workspace

0
Bernd van Oostrum (217●3●56●73) | asked Aug 22 '17, 4:10 a.m.
edited Aug 23 '17, 11:05 p.m. by David Lafreniere (4.8k●7)

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.

Accepted answer

2
permanent link
Ralph Schoon (63.5k●3●36●46) | answered Aug 22 '17, 4:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Aug 22 '17, 4:56 a.m.

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
Comments
Bernd van Oostrum commented Aug 22 '17, 4:54 a.m.

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


Thanks a lot for the confirmation, Ralph.

1
Ralph Schoon commented Aug 22 '17, 5:04 a.m. | edited Aug 22 '17, 5:06 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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
Geoffrey Clemm commented Aug 22 '17, 5:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 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).

Your answer

Register or 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.