The Rational® Team Concert™ Client for Microsoft® Visual Studio™ IDE

© 2016 IBM Corporation1

RTC Client Technologies Team

The Rational® Team Concert™ Client for Microsoft® Visual Studio™ IDE


Outline

A brief introduction Goals Getting started Working in the RTC Visual Studio Client


Outline

A brief introduction

Goals Getting started Working in the RTC Visual Studio Client


The .NET Clients

A Visual Studio Client Integration

Heterogeneity

A Common Jazz Team Server

A Visual Studio Client for .NET developersAn Eclipse Client for Java developers

A Shell Client for non-IDE RTC usersA Web Client for other stakeholdersCLI, MSSCCI, ISPF …

Powered by Jazz

Vision

Brings the Jazz vision to .NET developers :The value and experience that future Rational products can bring to software and systems delivery teams

A First Class Integration with Microsoft Visual Studio

to enhance developer productivity

Innovative Software Engineering

Team Collaboration for .NET Developers and Windows Shell UsersSource control, work item tracking, build, process & collaboration servicesLinks to test cases, requirements A Windows Shell Integration

A First Class Integration with Microsoft Windows Explorer to enhance productivity for Shell users


Rational Team Concert for Microsoft® Visual Studio™ IDE

Natively implemented in Visual Studio

A first class integration into Visual Studio

An extension of the Visual Studio IDE

Integrates into Editors, Properties View, Solution Explorer, Options pages, Toolbars, Menus, Tool Windows, Error View, Themes…

Integrates into Visual Studio as a source control provider

Supports all flavors of Visual Studio 2015, 2013, 2012 and 2010.

Developed using WPF - NET 4.0 is the minimum requirement

Follows Visual Studio international settings


IBM Confidential

We develop the RTC .NET Clients using the RTC Client for Microsoft Visual Studio

Source control, tracking, planning my work, builds using the Visual Studio Client

Team planning, reports, admin functions using the Web Client

Our builds are integrated with MS Unit tests that get run as a part of every build that’s fired

Builds for the Windows Shell integration use the Jazz build template for Microsoft Visual Studio solution

Note: the Shell integration is one of the .NET clients that we build using the client for Visual Studio

At any sprint, we use the client from the last sprint to build the client for the current sprint

Self-hosting plays an important role in helping us understand use cases for the .NET developer

It also helps improve quality. We’re the first ones to feel the pain of any broken feature.

Self-Hosting


Outline


Goals

Getting started Working in the RTC Visual Studio Client


IBM Confidential

Goals for the Visual Studio Client The Visual Studio Client is focused around developer use cases for the .NET

developer

Use this integration for source control, builds, tracking, planning your own work

Use browser clients for team planning, reports, admin functions

Note: The admin may need to use the Eclipse client for certain tasks that have not been web enabled yet, though a lot of parity work has been done in the last few releases• Some process customizations can only be done via Eclipse though most are now supported in the

web client• Creation of build definitions requires an Eclipse client as well

Emphasis on native integrations

Tool windows, Editors. Properties View, Options, Menus, Themes …

Client parity for developer use cases is very important to us, though parity does not mean equality.


Outline


Goals

Getting started

Working in the RTC Visual Studio Client


Downloads and Installs Downloadable from

jazz.net

https://jazz.net/downloads/rational-team-concert/releases/6.0.2?p=allDownloads has the download bits for 6.0.2

Installable via IBM Installation Manager

In your machine, you can install different versions of Rational Team Concert Client on different versions of Visual Studio at the same time

https://jazz.net/downloads/rational-team-concert/releases/6.0.2?p=allDownloads





A quick look at the RTC Client for Visual Studio


Before you get started Set Jazz Source

Control as the Source Control Provider

It’s typically set to None or Visual Studio Team Foundation Server

Once Jazz is set as the source control provider, Visual Studio will add Jazz bindings to managed files and folders in your solutions, once you source control them


Before you get started (cont’d)

Help is just a click away …

Log a bug

Ask a question in the forum

To switch quickly between RTC Windows, use Team Concert->Windows


Before you get started (cont’d)

You can configure RTC preferences via the Tools->Options pages

There are Source Control related options, and then general Team Concert options

We’ll discuss options applicable to specific operations as we go along

RTC supports Visual Studio themes in its views

If you change the theme, you need to restart Visual Studio for it to take effect

RTC dialogs and editors do not yet support themes


Joining a Team Typically, the first thing you’d

do would be to join a team

You could accept a team invitation from your lead. This would automatically join you to your team/project area upon authentication (more on this later)

Or if you know your repository URL and your project area, you could click on the Manage Connected Project Areas link or toolbar button

Once you’re authenticated by your RTC server, you’re set to get started


Authentication RTC supports different

authentication protocols, all of which are supported in the Visual Studio Client.

User name/password (Basic, Forms).• This is the only mode that works with the

team invitation

SSL Certificate

Smart Card

Kerberos/SPNEGO

Integrated Windows Authentication• Your CCM credentials match that of the

Windows user on your machine


Now that you’re logged in … Things get a bit more interesting The Team Artifacts View in

particular, shows up a bunch of information about your team: streams, builds, plans, work items and so on.

This is the centralized access for Jazz artifacts

Repositories, subscriptions

Drill down to streams, plans, reports, builds and so on


Understanding your team’s artifacts Repository Connections

The servers you are connected to

Project Areas

The project areas that you are interested in. • A project area is an area in a

Jazz repository where information about one or more software projects is stored.

Team Areas

The team areas that you are members of, across the project areas that you are connected to


Understanding your team’s artifacts (cont’d) Source Control

Components• Stores a collection of

files and folders, usually represents a software module

• Provides reuse

Streams• The shared area for

developers to collaborate on their work

• A collection of components


Understanding your team’s artifacts (cont’d) Work Items

Stories, features, tasks, defects … for tracking a release

Queries Executed based on a set of

conditions on work items in a project• Created by me, Planned For

Release 1.1, …

Group of work items in a result set

Plans Show work items for a release or

iteration

Use the RTC Web UI for planning

You can use the embedded Web browser (preference based)


Understanding your team’s artifacts (cont’d) Builds

Build Engines• Perform builds• Can support one or more build

definitions

Build Definitions• Based on various build templates, such

as Jazz Build for Microsoft Visual Studio, Ant, command line, or Maven.

Build engines and definitions can only be created via the Eclipse Client

Reports Use the Web UI for creating and viewing

reports

You can use the embedded Web browser (preference based)


Understanding your team’s artifacts (cont’d) Feeds

This is like your team’s newspaper

What’s happening, who’s doing what, and so on

You can subscribe to what you’re interested in


Your artifacts in the Team Artifacts view My Repository Workspaces

Your own private space in the Jazz repository. Your “checked-in” source code lives here till you share it with your team (more on this later)

Favorites

Anything that you want to look up quickly – your streams, builds, queries … you add here!

Most artifacts have an “Add to Favorites” menu option that lets you do that

Work Item History

Tracks your most recent work item activity

Sandboxes

Your local work folders on your computer that are managed by RTC, are tracked here.

We’ll talk more about these as we go along.


Filtering the artifacts You may want an

uncluttered Team Artifacts view where you see streams and builds only from team areas that you’re interested in

Filtering is the way to go

Choose the team area(s) or project area(s) you’re really interested in

Streams, builds, plans and shared work item queries that are not associated with your selection, will now be filtered out.


Outline


Goals

Getting started


New developer: work on a task or a defect

Experienced developer: implement a new feature

Other use cases


First Steps

Get familiar with your team

What team streams do you have?

Where are your builds?

What are the current plans for your team?

Does your team have any shared queries?

Next, you need to figure out what you should start working on


What should you do next? Has your team lead assigned

you some work?

The easiest way to figure that out would be to switch to the My Dashboard View.

Configure the “My Current Work” section and add your project area(s)

You’ll see work items assigned to you for the current iteration/release

You can similarly configure the other sections to see your pending approvals, your future work and so on.


What’s that work item? Double clicking on a work item assigned to you will open it in the editor The description of the work item and any discussions will help you

quickly get an idea of what your assigned work is. The Links tab will show you other related work items


More on Work Items Once you open a work item, it will show up in the Work Item History node, for your quick

reference.

If you have a work item number, you can search for the work item in the search box.

You can add a work item to your Favorites too, for easy lookup in future.

You can create/edit other work items via the Work Item editor.


Running queries In the last chart, did you notice the links towards the bottom?

Those are links that execute queries on work items, and give you back a set of work items that match the conditions specified in the query

One way of finding out all work items are assigned to you that aren’t resolved, would be to click on that first link.

You could also run the same query from the Team Artifacts View.

There are a number of queries out of the box, or that your team has defined and shared already, that you may find useful.

Note that My Current Work in My Dashboard showed you your assignments for the current iteration, whereas queries are customizable


Getting started with source control The next step would be to work on

the work item that has been assigned to you, i.e. the source code to fix the defect or implement the task

To do that, you’ll first need to load the source code for your project on your local machine

In RTC, you need to first create a repository workspace from your team’s stream

Your own private area within the Jazz repository

What you do there is by default visible only to you, unless you choose to share with others

At the same time it’s backed up in the repository, not just your local file area


Getting to the source code You can choose the

default options in the repository workspace creation wizard

Private workspace – contents visible only to you • you could have a

different read access scope to if you wanted to

Picks all components from your stream

“Loads” the workspace into your local system, into a folder of your choice – your “sandbox” or work area.


The sandbox Your work area

Where you’ve loaded a repository workspace

Or “shared” your source code with your team (more on share later)

The sandbox will show up in the “Sandbox History” node in the Team Artifacts view.

Your next step would be to explore the files and folders in your sandbox via • The Solution Explorer or• The Sandbox Explorer (more on

this later)

Any changes you make to the files and folders will be “tracked” by RTC (more on this in a bit)


Exploring via the Solution Explorer When a sandbox is set (load or

other operations), you’re prompted to open a solution from the sandbox in Visual Studio

Files and folders in the solution are managed by RTC source control

Menu options show up RTC menus

Icon overlays indicate the state of the tracked files/folders• Managed, checked in, incoming,

unresolved, …

Note: A sandbox can be shared between multiple instances of Visual Studio

You can connect to the same sandbox and work on multiple solutions simultaneously, if you need to.


Exploring via the Solution Explorer (cont’d) The Jazz Source control menu gets activated when you’re working on a managed solution.

The menu options apply to the current file selected in the Solution Explorer.

Jazz Source Control menu options also get activated on the file opened in the editor

The file Properties view now shows Jazz specific properties


Before you get started with the fix … … let’s talk about how RTC will

track the changes that you will make

Changes in your sandbox and your repository workspace(s) loaded into the sandbox, are tracked in the Pending Change view

Changes “flow” from the repository workspace to the team’s stream (the “flow target”) or vice versa

Related changes are grouped into logical units named “change sets”

So if your changes are across multiple files, you can still group them into a single change set if they’re all in the same component

Change sets do not span components


More about tracked changes Unresolved

Local changes on your local filesystem, that haven’t yet flowed to your repository workspace

Outgoing

Changes that you’ve “checked in” to your repository workspace, but that haven’t yet been delivered to your team’s stream

Incoming

Changes delivered by your team members, flowing from the team stream to the workspace. You would need to accept these changes into your workspace.

Potential conflict

Changes in the stream are in conflict with those in your repository workspace and will need to be merged once you accept

Conflict

You’ve accepted changes from the stream and they are in conflict with changes in your repository workspace, needs a merge

Suspended

You’re not working on these changes at the moment, they’re not active, but they’re stored in your repository workspace


Fix, review, deliver: fixing So you’ve narrowed down a fix to a couple of files, and want to understand the changes that have

already been made to those files in that area

Show History/Annotate help with finding out the changes made to the file chronologically, who made those changes, and what defects/features those changes were targeting

The history view shows 100 entries by default, but you could change that via the Options pages.

You could navigate to any related work item and follow the discussions and description to understand the context better.


Fix, review, deliver: fixing (cont’d) When you’re working on your fix, your local changes show up as “Unresolved” in the Pending

Changes View and in the Solution Explorer.


Fix, review, deliver: fixing (cont’d) To view your changes, you can invoke the compare editor via the Compare related menu options,

from the Pending Changes View or the Solution or Sandbox Explorers

Either the default editor, or an external one, set via the options pages

Note: compare editors are also useful in comparing incoming changes before you accept them, or comparing file states in the History view, or your current file against the file state in any repository workspace or stream, or …

Default Compare Editor

External Compare Editor


Fix, review, deliver: fixing (cont’d)

A good practice is to not leave your changes in the unresolved state, but to keep checking them in.

That way they’re stored in your repository workspace but are not visible to anyone else

You’re protecting yourself against local crashes which may end up in your changes getting lost

You can see the individual check ins in the check-in history of the file in the history view


Fix, review, deliver: building Any fix should have a

corresponding MS unit test case that started out red but is now green (more on this later)

A fix is only ready when unit tests are successful

Before you submit for review, it’s a good practice to run a personal build to make sure that there are no regressions (more on builds later)


Fix, review, deliver: reviewing Once your fix is ready, you will need to get it reviewed by your

peers, and then eventually share it with the rest of your team The “Submit for Review” menu option in the Pending Changes view

lets you

Attach your changes to a work item and

Choose an approver in the work item

It also automatically completes your change set – you can’t add more changes to it• Note: change sets can be active or completed. You can add more changes to active

change sets.


Fix, review, deliver: reviewing (cont’d) When the changes are submitted for review,

The reviewer would typically get an email, and it would also show up in their feeds

The reviewer would then open the changes using the “Change Summary” view and review them

The reviewer could also accept the changes into their workspace right from the work item, and review and test with those changes as well

We have a more sophisticated web based code review too (more on this later)


Fix, review, deliver: reviewing (cont’d)

Review takes some back and forth discussions, all of which are usually recorded via work item comments

Once the reviewer is satisfied, s/he approves in the work item


Fix, review, deliver: merge with incoming Before you deliver, you need to

Accept incoming changes if any, for the component you’re delivering against

Resolve merge conflicts if any, using your compare/merge editor

Re-run a personal build and make sure it’s green


Fix, review, deliver: delivering You can now deliver your changes to share them with your team. Deliver brings the state of the delivered files to be the same in your

repository workspace and stream, and they will no longer show up in the Pending Changes view.

The defect is now fixed.


Can I deliver without reviews? Depends. This is where the RTC process kicks in.

So if your team process mandates that you need reviews before you can deliver, then you won’t be able to deliver without reviews.

If your process mandates that your role cannot deliver to a team stream, then you won’t be able to deliver at all, reviews or not.

Note: RTC’s process applies automatically to operations, you don’t need to remember it. However to understand why some operations fail for you, it would be good to get an overall understanding of your team’s process.


Can I deliver … (cont’d)

Do I (does my role) have permissions?

Did I follow the process?


What happens if I try to deliver without reviews? If the RTC process mandates a review, then your operation will fail

You will be shown a “Team Advice” which will tell you what went wrong and give you suggestions on how to fix it

Note: when any operation fails because of non-compliance of process rules, the Team Advisor pops up with some guidance

The next chart talks about the power of RTC’s process


A bit more about process Your admin can define a flexible and customizable set of rules in the

process that control the behavior of most RTC operations

Who can triage work items, fire builds, edit a project area, deploy reports, create a stream …

Is there everything going for this operation to execute?• For example have all the mandatory work items attributes been set? Do you

have enough reviews and approvals for delivery? Can you fire a build or are there too many in the pipeline already? …

Process rules can be set up for a project area and then customized for individual team areas

Process rules can be customized for specific sprints too At any time what rules apply to the operation you’re executing, depend on

your project area, your team area, your role in the project/team area, and the sprint.


Building your changes RTC provides a build template for

building Visual Studio solutions

It uses devenv or msbuild to build the sources

You can also hook it up to MS Units or Nunits as a post build step

Your build admin can also use a more generic build template such as an Ant or a command line based one

Creating a new build definition is supported only in the Eclipse Client

You can fire a build or view build results from both the Visual Studio and the Eclipse Clients


A sample build result


Outline


Goals

Getting started




Other use cases


Implementing a new feature Whether you’re fixing a defect or implementing a new feature, most of the

workflows are essentially the same.

The one new workflow that we haven’t talked about yet is “Share”

This operation applies when source code for the new feature is in a new project or a new solution which is not yet being managed by Jazz source control

To start tracking such new code in RTC, you need to run a “Share”

Note that we’ve talked earlier about sharing your source code with your team via a deliver operation. This though is somewhat different – it’s the “share” operation – adding a project or solution or a top-level folder to Jazz Source Control for the first time.

It’s like a first time check-in of sources

Source control bindings will be written into the shared solution or projects

After a share, you’ll still need to deliver your changes for your team members to actually see the changes

We’ll talk a bit more about share options and the use cases they serve, in the next few charts


Sharing a solution Share a solution against a

new or an existing Jazz component

In a new or existing repository workspace

There may be files or folders that you do NOT want source controlled

Binary files, .suo files for example

RTC offers you a prepopulated list of commonly “ignored” files and folders, that you can edit


Sharing a solution (cont’d)

Once share completes, all files and folders in the solution explorer are checked in to the Jazz component that the solution was shared against

Visual Studio adds source control bindings to the projects and solutions shared

If new projects are added under a shared solution (i.e. to its hierarchy), they need to be shared as well

But in this case share will just add Visual Studio bindings, the component and repository workspace are pre-determined.


That’s all very well but …

How would you tie these solutions together, after all in the real world there will be dependencies between your modules, they won’t run independently in vacuum!

Wouldn't it be more intuitive to share projects instead of solutions? What will your builds build? You don’t want a build for each module, you

want one that builds your whole system! Enter “partitioned solutions”


Partitioned solutions This is one of the more popular approaches of organizing your projects and

solutions, and one we follow ourselves in our .NET source code.

Our code is divided into modules, each module is represented by a solution.

Each solution is “shared” against a Jazz component representing that module

Each solution has one or more projects in its hierarchy, in the file system

All projects in a hierarchy are shared against the same Jazz component as the parent or “home” solution

How do we handle cross component dependencies?

Projects are created in “home” solutions, and included as “existing projects” in other solutions as needed.

We also have an “umbrella” solution for each of our .NET clients, which includes projects from other solutions as needed.

All our MS unit test projects are in this solution

This is the one that gets built by the automated builds, and tests from the MS Unit tests are executed as a part of the build.


The RTC.Net Client solution … This solution and associated projects have the source code for the RTC

Client for Visual Studio.

RTC.Net, the “umbrella” solution

AuthenticationUI, included in “RTC.Net”

AuthenticationUI, homed in “Process”


… and layout of source code

RTC.Net Solution folder structure

Sandbox Folder StructureProcess Solution folder structure


Partitioned solution - observations The solution folder, that contains the solution file and the projects in the

solution, is directly under the share root (the share root is the top level folder under a sandbox, that’s shared against a component)

Sharing is done from within the Solution Explorer, and Visual Studio adds source control bindings to the projects and solutions

All projects under the “home” solution hierarchy can be shared only with the component that the solution has been shared against

Sharing therefore is solution centric, and there’s usually one solution per share root


Sharing a project Why?

We understood from some users that they used solutions mostly as placeholders, for them projects were the first class SCM members

Some users found sharing projects more intuitive that sharing solutions – their source code hierarchy usually consisted of one solution with multiple projects in the same hierarchy, and one or more projects represented a module.

They didn’t want to unnecessarily group projects into separate solutions in order to be able to share them

To serve such use cases, RTC Visual Studio Client lets users share projects directly into Jazz components

This is also useful when you want to share website projects against Jazz components

The solution file for such projects is often a temporary placeholder and the projects are not usually in the solution folder’s hierarchy


Sharing a project (cont’d) The project folders are directly under the sandbox

The solution is usually more like a temporary placeholder, that’s not shared against a component

Visual Studio writes bindings into the projects but not the solution


Sharing the .sln file What if you wanted to

share projects instead of solutions, but at the same time wanted to make it easy for your team to load the solution hierarchy via Visual Studio?

Starting 6.0.2, you could additionally share the solution file as a top level file into a Jazz component.

Visual Studio won’t write any bindings into it

The solution file can be shared via the Sandbox Explorer


Sharing a top level folder

As .NET developers you will mostly work with projects or solutions, so most of your share operations will be executed via the Solution Explorer, so that Visual Studio can add source control bindings

However, you may have the occasional need to share other types of files, such as third party libraries, functional specifications, help files …

You can do this by creating a top level folder under a sandbox, putting your files there, and then sharing it from the Sandbox Explorer


What next? Most of the RTC workflows for implementing a new feature or fixing a defect in the

defect backlog, are pretty much the sameImplement

Check-in/Share

Review

FixCheck-in

Ready

Accept/Merge

Deliver

Test

Test

The ways of working could be somewhat different though

In the next couple of chart we talk about what we practice in our development team

Build

Build

Build


Implementing a new feature vs fixing a defect Most of the RTC operations are pretty much the same whether you’re

working on a new feature or fixing a defect, but there are some differences in the ways of working based on what you’re doing, not specific to .NET developers…

In the RTC team, we have “Feature Teams” doing features and “Run Teams” taking care of the defect backlog

Feature Teams usually work on side streams called feature streams. Feature streams accept changes at regular intervals from the component integration stream, but deliver only when the feature is tested and almost done. Run teams work directly on integration streams.

Features are usually tracked in high level work items such as epics and stories, which are broken down into execution tasks. Run teams on the other hand work on execution items such as defects and tasks.

We’ll leave the other details out of the scope of this discussion


Outline


Goals

Getting started




Other use cases• Multi-tasking• Working with your team• Working on parallel releases• Are my changes there in that stream/workspace?• Refactoring• Code Reviews


Other use cases

In the next few charts we discuss some of the more common use cases and how they’re served in the RTC Visual Studio Client

These are by no means exhaustive If we’ve missed out an operation that’s important to you on a regular

basis, your feedback is welcome


Outline


Goals

Getting started






Suspend and resume What happens when you’re

working on a task and a high priority must-fix defect suddenly pops up in your backlog with tomorrow being the due date?

What you can do is check in your current changes and “suspend” the change sets

Once the change sets are suspended, they’re no longer part of your local work. They’re saved in your repository workspace but do not flow anywhere.

You can suspend active or completed change sets


Suspend and resume You can now work on the high priority task, complete it, get it

reviewed and delivered Once you’re done, resume your suspended change sets, and they

once again become active and tracked in the Pending Changes View


Outline


Goals

Getting started






Conflicts and merges

It may sometimes happen that you and a coworker are working on defects that require code changes in the same file

Your changes are ready, but she beats you to delivering to the stream

And now you have potential conflicts showing up in your Pending Changes view

You could try to deliver, but RTC doesn’t accept conflicts in the stream, and rightly so.



So your only choice is to accept, when the potential conflicts become real conflicts

At that point you could try resolving or you could try merging.

If you Resolve with Proposed, you lose your changes

Resolve with Mine overwrites and overrides the incoming changes

Resolve as Merged indicates that you’re done merging

The recommended way would be to try and merge the changes via the compare editor



You can choose the default editor or a third party one as discussed in the earlier charts

You can ask RTC to Auto Merge if there are no overlapping changes, and many times it would just work

However there could be some merges that you’d need to do manually

When you’re done merging, click on Resolve as Merged


File locking If you and others are constantly

working on the same files, then merging may get tedious

You could then choose to lock a file in your team stream

Locking gives you exclusive write rights to a file

No one can deliver change to the file unless you unlock the file

It’s also possible to set up auto locking for files in RTC streams, based on specific patterns.


Outline


Goals

Getting started






Changing flow targets You’re working on a fix for a defect that

needs to be fixed not only in your current release, but also in maintenance streams for older releases

You could make the fix in your workspace that flows to one of the streams – main development or maintenance and then change the flow target of your workspace to the other stream and deliver the change sets there too

You could change the flow target for the component or the group of components that contain the fix change sets, or for your repository workspace

If there are merge conflicts, then just changing flow targets wouldn’t work. You would need to make the fix separately for each release


Outline


Goals

Getting started






Locating your changes You’ve fixed a bug but you’re not quite

sure if you’ve delivered it to an older stream

You could just try locating your change sets in the streams that you’re interested in, using the “Locate Change Sets” option on the work item

The results indicate whether some or all of your change sets have made it to one or more of the streams you’re interested in


Outline


Goals

Getting started






Refactoring

You’ve implemented a feature, and after code reviews you realize that the feature needs some design changes and some of the UI code should move to a different project

Or there’s some common infrastructure code that should move to its own reusable module i.e. Jazz component

The feature has gone through several rounds of reviews and fixes and you want to preserve the history of your changes

The Move options in the Sandbox Explorer let you do that

The Solution Explorer does not preserve history when moving files and folders across projects


Move in the Sandbox Explorer The Sandbox Explorer offers options for

move while preserving history It does not have a notion of projects, but you

could move files and folders across top level folders (often project folders) and it would preserve history if the folders belong to the same RTC components (Move option)

It also supports moving folders across components preserving history (Move in Repository Workspace option)

You’ll need to fix up file/folder inclusions/exclusions in Visual Studio projects after a move, using the Solution Explorer


Outline


Goals

Getting started






Reviewing Code

RTC has an advanced web based Code Review tool that can be used for interactive and collaborative code reviews

It’s integrated with Rational Team Concert work items and Jazz source control.

There’s a new code review presentation that you can attach to a work item type in the Project Area editor.

It shows a code review in progress, lists the change sets, target stream, and issue status.

It also presents a list of files in the change sets where you can see who has reviewed a specific file along with links to open must-fix issues


Set up To enable the new code review feature in 6.0.1, your admin needs to set it up via

the project area editor in a browser client

Your project admin needs to add an approval attribute for Code Review for code review to be enabled in your project.

Since 6.0.1


Reviewing Code Here’s a glimpse of the code review tool in action


In conclusion

This completes the introduction to the RTC Client for Visual Studio We’ve tried to make this presentation use case focused rather than

feature focused We haven’t discussed the advanced features here – just the more popular

basic use cases Hope you find this useful


Thank you

Technology

The Rational® Team Concert™ Client for Microsoft® Visual Studio™ IDE