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

RTC Source Control - How Can I Configure a Network Sandbox So it Can Be Loaded by Two Users?

Questions
Tags
Users
Badges
Nate Decker
(378●1●47●61) edited
Dec 16 '15, 1:18 p.m.
Background

We have a network folder that must be available to users who do not have CLM. However, the content of that folder is populated by users who DO have CLM and want to maintain those contents in Source Control. We have some users off-site who have access to CLM, but not the network folder and we would like a gatekeeper person in that group to be able to load our component within their own network folders. 

What We've Done

We have had a user configure the source network folder as their personal sandbox and then deliver sandbox modifications to the server. Any user who has network access can read data from the folder and if they have permissions to write, they can put data into the folder as well. The owner of the sandbox would see this added data as pending changes they need to deliver so this keeps the owner updated on the changes to the network folder and gives them a chance to vet those changes.

What We Want to Do

This works pretty much how we would like. However, it would be nice if our team could collectively administer the network folder in order to improve our responsiveness to changes to the contents (i.e., deliver them to the stream faster). It would also allow us to distribute the workload so that multiple people could vet the pending changes and accept them rather than relying on a single gatekeeper.

The Problem

We tried to have two users share the same network folder as their local sandbox, but CLM disallows this because there is a lock file in the .jazz5 folder that is tied to the first person who configures the folder as their sandbox.

I can understand the importance of having a single person be the gatekeeper on changes, but at the same time it seems like there is value and importance in having redundancy and fail over. Is there a way to do what we are trying to do?

0 votes

Comments
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Dec 20 '15, 4:51 p.m.
Just for interest's sake, why do those users not have CLM?   There are many reasons for each CLM user to have their own private sandbox (such as tracking change sets correctly).

Nate Decker
Dec 21 '15, 9:06 a.m.
Geoffrey, they don't have CLM because their projects have not bought into the tool. In our organization we are trying to make the CLM suite the standard set of tools for all projects but there are a handful of holdouts who refuse to get into the new tool. They may have their own set of tools they've used historically and they don't want to migrate and deal with the overhead of learning the new tool and moving the data etc... We're hopeful they will change their minds eventually. We use the aforementioned network folder for trainings and presentations. Some of these presentations/trainings we use when trying to persuade projects to adopt CLM.

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Dec 21 '15, 3:54 p.m.
I thought that might be the reason (:-).    Having them use RTC in this crippled fashion is unlikely to motivate them to switch.   I'd suggest instead creating a set of workspaces that are dedicated to migrating data between their SCM system and RTC (and implement some scripts to automate that migration), and not try to use the same workspace for both "real work" and for migrating information between another SCM system.

2 answers
5,593 views
0 votes

2 answers

Permanent link
Surya Tripathi
(650●1●7) Dec 16 '15, 7:00 p.m.
I am not sure if a source control system can handle this very well. Sandbox is considered private and should not be used by multiple users.
Not sure how practical it sounds, but could you try something like this ?

1.  Keep a single machine for pushing the changes. So, all gatekeeper will have access to this machine and they all will  share the same RTC account to push changes to the stream.

2. Create a sandbox on the network, one for each gatekeeper. Designate a gatekeeper at the beginning of the day and have all NON CLM users switch to this new sandbox. The gatekeeper will need to copy files from old sandbox to the new one.

3. Convert NON CLM users to CLM users so they all have a workspace of their own and then use a a stream as the central hub so everyone can access it.

0 votes

Comments
Nate Decker
Dec 17 '15, 8:31 a.m.
Thanks for the response. We had considered a possibility similar to this as well. However, it felt like a brute force solution that was more of a workaround than the intended usage of the tool. I was hoping there might be a way to do this within the scope of the existing expected usage model. I guess this sort of answers my question that there isn't some snazzy feature or nuanced capability that I'm just missing.

Permanent link
Donald Nong
(14.5k●6●14) Dec 16 '15, 8:32 p.m.
I suggest the below idea but you need to test it out and see if it works well for you.

The gatekeepers (CLM users) have to use separate repository workspaces and their own sandboxes - this is to avoid the dreaded "project out of sync" error. Use a dedicated CLM user to provide the contents to non-CLM users - similar to your original configuration but without the ability to check in (think a build user).  Synchronize the project folder(s) from the dedicated CLM user's sandbox, that is, excluding the .jazz5 folder to the gatekeepers' sandboxes - this can vary a lot in the implementation. For example, you can set up a periodic copying task to copy the contents from the shared sandbox to the gatekeepers' sandboxes, ideally retaining all timestamps and file attributes. But if a gatekeeper would also modify the contents, you may let the gatekeeper to initiate the synchronization to avoid her own changes from being overwritten by the scheduled task. Of course you will need to "accept changes" to the shared sandbox regularly so that the non-CLM users can see the up-to-date contents.

0 votes

Comments
Nate Decker
Dec 17 '15, 8:37 a.m.
Thanks for the response. This is probably similar to what we'll end up doing. Either that, or we'll just assign a single person to be responsible for updating the network location (sandbox) and delivering those changes and let everyone else accept changes from the stream. The single person (gatekeeper) doesn't have their own sandbox on their local machine, they just use the network folder directly so we wouldn't need to worry about keeping it synchronized beyond having them regularly accept deliveries. The single person approach is what we've done historically so it wouldn't be hard to just keep doing it. It sounds like there isn't really a way to share ownership of the sandbox with respect to accepting deliveries and having that accept action update the sandbox (more than one person can accept, but the accept action only updates the network data if the person who accepts is the person who loaded the component to that sandbox location, and only one person can do that). I had wondered if there was a way to delete the lock file in the .jazz5 folder, but that's probably asking for trouble. Thanks for the suggestions.

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.

Ask a question
Guidelines
FAQ
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,144

Question asked: Dec 16 '15, 1:14 p.m.

Question was seen: 5,593 times

Last updated: Dec 21 '15, 3:54 p.m.

Confirmation Cancel Confirm