Working with the Sandbox Explorer in the Rational Team Concert Client for Microsoft Visual Studio IDE
Sreerupa Sen, IBM
Last updated: May 09, 2017
Build basis: Rational Team Concert 6.0.4
One of our goals for the Rational Team Concert Client for Microsoft Visual Studio IDE is to make it easier to use source control features. The Sandbox Explorer view lets you work with files and folders in your sandbox, regardless of whether they are part of your current solution hierarchy or any solution hierarchy. This article describes some scenarios in which it helps to use this view.
The Team Artifacts View has a folder named Sandboxes, which has a list of the sandboxes that you worked with recently. This folder makes it easier to remember where your workspaces were loaded, which is especially useful if you work in multiple projects or with multiple releases simultaneously. The sandbox that you’re working with in your current instance of Visual Studio is tagged as your Current Sandbox.
You can pick any sandbox from the list and set it as your current sandbox. You can create a new sandbox by invoking New Sandbox on the Sandboxes node. Selecting Explore on a sandbox sets it as your current sandbox and brings the Sandbox Explorer view into focus.
The Sandbox Explorer view lets you browse to and work with files and folders in your current sandbox. It supports all the SCM operations that are supported in the Solution Explorer. Additionally it supports move, rename and delete operations on files and folders, while preserving history.
Working with your source code
In the following sections, we see Cindy Sharp, a Visual Studio developer, working with the Rational Team Concert for Microsoft Visual Studio IDE. She initially starts with a single solution and a few nested projects and folders. She later decides that some common code can be moved to its own component to facilitate re-use of this component in other projects. She also decides to place her functional specifications under source control. Read on to see the steps she takes.
In Jazz source control, the fundamental organizational unit for source code is a component. You typically put related projects and folders together in a component (for example, projects that are built together or form a subsystem).
Cindy is working on a project that consists of three subsystems, Rich Client, Server, and Web Client. She has a bunch of requirements documents and test cases for these subsystems.
Cindy initially starts with three Visual Studio projects in a solution: RichClient, Server, and WebClient. In the future, she will probably move each of these projects into different solution hierarchies, but right now she wants to keep it simple. This is how Cindy’s solution looks at this point.
Cindy wants to create three Jazz components, one each for the Server, Rich Client, and Web Client subsystems, and share her projects with those components. She can share projects under the same solution into different Jazz components. The solution won’t be shared in that case, but she isn’t worried about this solution anyway – it’s just a container for the projects.
Cindy right-clicks on RichClient and selects the Share Project(s) in Jazz menu option. A window pops up asking her to choose a sandbox location. The solution folder, which is the parent folder for the project folder, is the default sandbox location. Cindy accepts the default value because she wants the project folders to be the top-level folders that are shared under a component.
In the next steps, Cindy creates a workspace. She decides to flow her workspace into the ClientServer Project Area Team Stream stream and there she creates a component to share her project into.
Finally, she selects the files and folders that she would like to ignore while sharing.
She repeats the same steps for the other two projects. At the end of the share, each project is shared into a Jazz component. The Properties view for the files and folders now displays Jazz Source Control related properties as well.
Cindy wants to take a look at her sandbox, so she navigates to Team Concert > Windows > Sandbox Explorer. She could also have chosen to Explore her sandbox from the Sandbox history in the Team Artifacts Navigator.
The Sandbox Explorer shows that the project folders are checked in, but the solution files are not, which is expected. Ciindy now delivers her changes from the Pending Changes view.
Note: Before the 3.0 release, the only way that Cindy could have shared the projects to different Jazz components was to have created a solution for each project and share the solution to the component.
After a few days of development, Cindy has added more functionality and projects to her components. In particular, she has a ClientLibrary project that she has shared into the Rich Client component, but which she now realizes can be used by the Web Client component as well. She wants to create a common component and she wants to share ClientLibrary against that component. However, she and her team have done quite a bit of work on the library already, and she doesn’t want to lose the history, which will happen if she disconnects and re-shares the project. She can use the Move in Repository feature to move ClientLibrary to a new common component.
Note: The Move in Repository feature is available for all folders and can be used to move folders across components or within components, preserving history. For top level folders, a destination component needs to be selected. For inner folders, you can select a parent folder in your sandbox, and Rational Team Concert calculates the destination component. In contrast, the Move command in the Sandbox Explorer preserves history for files and folders only if the move is within a component.
This is how ClientLibrary looks prior to the move. From the Properties view you can see that it’s shared to the RichClient component now. Parser.cs already has quite a bit of history in the repository.
Cindy opens Cindy’s Client Server Workspace. She creates a new component named Common Client and saves.
Cindy navigates to the Sandbox Explorer, right-clicks on the ClientLibrary folder and selects Move in Repository. She selects the newly created Common Client component as the move destination.
ClientLibrary is moved to Common Client. Because Common Client isn’t loaded, Client Library disappears from the Sandbox Explorer. From the Team Artifacts view, Cindy loads Common Client.
Cindy receives prompts about project overwrite and reload, since she’s reloading the same project that was earlier shared to Rich Client. She clicks OK. From the Sandbox Explorer, Cindy selects Jazz Properties on ClientLibrary. This time ClientLibrary appears shared to Common Component.
The Pending Changes view contains an outgoing change set from Rich Client with a comment about the Move. Cindy creates a work item for the move task, associates it with the change set, and delivers the changes.
The Move’s successful. Cindy looks at the history of Parser.cs. The old history’s all there, in addition now there’s the Move related comment at the top of the History view.
Working with folders
Cindy has a bunch of functional specifications that she wants to share with the team. She creates a component named Functional Specs. Next she creates a folder named Functional Specs at the top level in her sandbox, via the Windows Explorer.
She copies all the documents to the newly created folder. She then opens up the Sandbox Explorer and does a Refresh at the sandbox folder level. Because the folder was created outside of Visual Studio she needs to click Refresh to have it show up in the Sandbox Explorer. Then she right-clicks on the folder in the Sandbox Explorer and selects Share Projects in Jazz.
The share wizard comes up and Cindy shares the folder to the ‘Functional Specs’ component.
About the author
Sreerupa Sen is a developer in the team that’s developing the Ratonal Team Concert Client for the Microsoft Visual Studio IDE. She can be contacted at email@example.com.
© Copyright 2010 IBM Corporation