Hi Richard,
I can not test that right now, but I think I remember from 3.0 you can switch between sandboxes. You could have more than one sandbox loaded to your machine and change the active sandbox.

Hi Richard,
I'm not really sure what you meant by switching back and forth in this particular context - repository workspaces? sandboxes?
Here's how we do it in the RTC VS Client team. We have a repository workspace that flows to the maintenance stream and another that flows to the main development stream. The repository workspaces are loaded in different sandboxes in the filesystem. If we fix a bug in say the maintenance stream, we accept the change set(s) from the work item into the main development workspace. Or if it's a simple fix, we change the flow target of the maintenance workspace to the main development workspace and deliver the change there as well.

This change may need to be merged in to the main workspace or may produce compile errors. That's why it's first
delivered to a repository workspace, compiled, tested and
then delivered to the main development stream.

The workspaces are loaded in different sandboxes. In the VS Client's the Team Artifacts Navigator there's a node named Sandbox History under which we have an MRU list of the sandboxes. Using the context menus on these sandboxes it's easy to switch sandboxes.

If this isn't what you asked, please let us know.
Cheers
--Rupa

Hi Rich,

Here's a shot at answering your question based on what I've understood. In some of the steps, there are multiple ways of doing things, I've just stated one to keep this short.

Let's say I'm going to work on two releases - a maintenance one 1.1 and a release one 2.0. At the start both of them start from the code base of 1.0.

So at the start I duplicate Stream_1.0 into Stream_2.0 and Stream_1.1, using the 'Duplicate' menu item on a stream in the Team Artifacts view.

Next I create two repository workspaces for myself - Rupa_1.1 and Rupa_2.0 from Stream_1.1 and Strem_2.0 respectively. I can do that via the 'New Repository Workspace' menu item on a stream.

I load Rupa_1.1 into c:\mysandboxes\1.1_work and Rupa_2.0 into c:\mysandboxes\2.0_work. Note that these are two different sandboxes altogether and they share a parent for convenience - you could load them into entire different folder hierarchies. It's important that you load them in different sandboxes, otherwise you may end up overwriting your code.

Now I start working on 2.0 delivering into Stream_2.0 and 1.1 delivering into Stream_1.1. I have a VS instance opened on a solution or project in c:\mysandboxes\1.1_work, delivering into Stream_1.1. I have another VS instance opened on a solution or project in :\mysandboxes\2.0_work, delivering into Stream_2.0. Note that I cannot work on two different sandboxes at the same time from the same RTC VS instance.

I make a bugfix to file File1.cs in c:\mysandboxes\1.1_work, which gets delivered into Stream_1.1. I need to deliver the same into the 2.0 release as well. There are various ways of doing this.

One Way
---------------
1. After I deliver my changes to Stream_1.1, I use the 'Change Flow Target' menu option on Rupa_2.0 in the Pending Changes view, and change the flow target to Stream_1.1
2. I'll see lots of changes. I carefully choose the one I want to accept, I accept that change set to Rupa_2.0 from Stream_1.1.
3.If there are conflicts, I merge and resolve them.
4. I switch my flow target back to Stream_2.0 and test and deliver.

Another Way
-----------
1. I associate my changeset with work item 123 when I deliver in VS instance 1.
2. In VS Instance 2, I open up work item 123, and from the menu in the work item editor, I choose 'Explore Change Sets'.
3. This opens up my change Set(s) in the change explorer.
4. I multi-select the changes I need and 'Accept' them into my
workspace.
5. I may need to work on them some more, or test them in the 2.0 code base. Once I'm done, I deliver it to Stream_2.0.
6. Sometimes it may happen that File1.cs has moved along in the 2.0 code base, and in that case, the accepted changes cannot automatically be merged into my workspace. Instead RTC will create what it called a 'Patch' which will show up in my Pending Changes view and which I will have to merge with the 2.0 code using the 'Merge into Workspace' command.

This is a rather long winded response - I hope you find it useful. If you don't, please feel free to ask questions.

Here are some articles I found;
http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/index.html
https://jazz.net/library/article/40

Cheers
--Rupa