It's all about the answers!

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

×42,845
×11,979
×4

question asked: Dec 14 '12, 4:42 p.m.
question was seen: 5,203 times
last updated: Dec 19 '12, 11:34 a.m.

Related questions

Is it possible to have multiple local sandboxes off the same stream?

0
Mark Odell (11●1●1) | asked Dec 14 '12, 4:42 p.m.
We've just switched to RTC at work and we're having a hard time trying to figure out how to have multiple sandboxes based off the same stream and still have Eclipse/RTC recognize each sandbox as an RTC "project". For example, I have a stream with two repository workspaces flowing into it: 

dev-foo

|

+-- rw1 (loaded) --> ws1

|

+-- rw2 (loaded) --> ws2

I have loaded rw1 and rw2 on my file system to /home/workspaces/ws1 and /home/workspaces/ws2. In each sandbox, ws1 and 2, I have the a "root" dir called 'foo'. I loaded rw1 to ws1 first, then rw2 to ws2.

If I start Eclipse and point it to /home/workspaces/ws1 I see 'foo' in the Project Explorer and I can make changes and see them show up as unresolved. All is good.

When I switch workspaces (either by switch workspace or close/re-start eclipse) and point eclipse the /home/workspaces/ws2 I have an empty Project Explorer window and thus I can do no work within the realm of RTC.

What am I missing?



2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Andrew Hoo (1.0k●1) | answered Dec 17 '12, 11:36 a.m.
JAZZ DEVELOPER

You're on the right track. You can read up this basic workflow here: https://jazz.net/library/article/41 (in your case, think of rw1 as Jason and rw2 as Markus).

One correction to make first though is that you cannot have any "local workspaces" off the same "stream". (and here I am referring to streams as being different than repository workspaces, even though they are similar in some aspects). Notice your own diagram that you made - your local workspaces ws1 and ws2 are connected to rs1 and rs2. Those edges are very different than the edges that connect rs1/rs2 to dev-foo.

You have a stream with two repository workspaces - good

You have each repository workspace loaded to their own local sandbox - good.

There are 3 more steps:

1) Check in your unresolved change from ws1 to rw1 (into a change set). Unresolved changes are only known by your local machine. The tutorial suggests that you can turn on auto-checkin if you prefer that workflow. That way ws1 and rw1 will always "be in sync". (there are pros and cons to having this turned on, that I will leave out)

2) Deliver your change set from rw1 to the stream dev-foo. Generally, you can think of Repository Workspaces as private copies of streams. They are a place for you to do your work. When you are ready, you deliver change sets to the stream which are places for an entire team to do collaborative work. In a simple work flow, other Repository Workspaces cannot readily get your change set until it makes it's way "up" to the stream first.

3) Accept the change set from stream dev-foo to rw2. Accepting change sets will automatically sync rw2 with the local sandbox ws2.

Now if you switch eclipse workspaces, you should have your modifications.

Comments
Mark Odell commented Dec 17 '12, 1:25 p.m. | edited Dec 17 '12, 1:27 p.m.

Thanks so much for taking the time to answer. Much appreciated. I'm glad to see that RTC supports multiple repo-ws's and local sandboxes off of one stream. This makes me think that my question is really more about how Eclipse and RTC interact with workspaces/sandboxes. Also, unlike the example you noted I am not logging in as a different user - I am the same user trying to use two local sandboxes simultaneously.

In my case, I use ws1 (Eclipse workspace) for developing code, bug fixing, and testing. I use ws2 for testing only. Note that ws2 will never have any of my undelivered changes from ws1/rw1. Sometimes, I get myself into a rathole where I have several change sets, each with a different set of files, and each for different defects in progress at once. Someone wants fix #1 immediately so I deliver it to dev-foo and then accept it over in ws2 to test fix #1 and only fix #1.

[continued to next comment]

Mark Odell commented Dec 17 '12, 1:26 p.m.

[continued from previous comment]

Once I'm happy I deliver my changes for fix #1 from dev-foo to int-foo where the integration testing for the stream is done. This was trivial and simple to do with AccuRev but we're finding it more complicated with RTC/Eclipse. To wit, Eclipse will not show any RTC'isms on ws2 (I loaded this sandbox second after ws1). In fact, Eclipse's Project Explorer is completely empty when I switch to Eclipse workspace ws2. In ws1 I see the root item 'foo' and all my sources under that root "folder". We simply cannot get Eclipse to show the RTC root level project in more than just the very first sandbox that we load. I guess that's our real problem.

0
permanent link
Kevin Mayfield (43●5●8) | answered Dec 18 '12, 4:54 p.m.
edited Dec 19 '12, 11:34 a.m.
When you started Eclipse, I assume you started it with workspaces/ws1 as your Eclipse Workspace (ews1).
See /home/workspaces/ws1/foo/.project.

I am guessing you loaded the second repository workspace (rw2) into your sandbox ws2, from the SAME eclipse workspace (ws1) but using the advanced option.  Eclipse will not create another Eclipse Project (ews1) since it would have the same name as the first (i.e. "foo" in the sandbox directory foo).

See that /home/workspaces/ws2/foo does not have any .project.

Instead, before you attempt to load rw2, switch to your ws2 in eclipse.  You may need to add your Connection information again.

Now load rw2 into ws2 (no need for advanced option) and it will allow you to create the Eclipse Projects for the loaded projects.

Switching back to ws1 will work as well as opening a second instance of Eclipse using ws1 as the Eclipse Workspace.

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.