CA SCM Visual Studio Plug-in – Video in YouTube

There are two videos posted -
> Add Solution to CA SCM
> Open Solution from CA SCM, Concurrent Development.

Parallel Development – Get Latest Versions/Update From Repository

In earlier posts we have come to know about Synchronizer, which showed the differences between local workspace and repository.

Get Latest Versions

or

Update

This is next step after user has performed “Synchronize”. Which means, after you see the differences between your local workspace (In Visual Studio) and CA SCM repository, if you want to update your workspace with the latest changes (versions) from repository – you have to use “Get Latest Versions” or “Update”.

If you have Synchronized by selecting solution (in Solution Explorer), it will show all the diffrences that has been made to local workspace and the corresponding repository path in repository.

We will now see this by an example. User ‘User1′ creates a new project and adds to CA SCM repository using his Visual Studio IDE (IDE1).

 

Create Project & Add Solution to CA SCM

Another user ‘User2′ opens the solution using his IDE (IDE2) in a different machine.

Open Solution

User2 now sets context and adds a new project to the solution and then commits all changes to repository.

Add Project to Solution - User2

Add Project & Commit

User1 selects the solution and performs “Synchronize”, this shows some new stuff has been added to the repository path.

Synchronized

User1 selects and right clicks on the solution from Synchronizer window and selects “Update”.

Workspace Updated - User1

Now User1′s workspace is updated with the changes made by User2.

How can I “GET” an older version to work

Sometimes we may need an older version of a file to work. Let’s say, the file has 4 versions (0, 1, 1.1.1, 1.1.2). The latest version is 1.1.2, but we want version 1 in workspace to make the changes.

To achieve this, we have to know about following functionalities:

Versions

Get

“Versions” is a menu item (right click) in Solution Explorer. Right click on a managed file, select “CA SCM -> Versions”. This will list down all the versions available in CA SCM repository for the selected file in Solution Explorer. It shows all the versions in “SCM Versions List” window within Visual Studio IDE.

“Get” is available from “SCM Versions List” window. You can select any version of the file, and click on “Get” (icon) in the toolbar of this window. This gets the selected version (with its content) into the workspace (Solution Explorer). “Get” is also available as a right click menu item from this window.

Now, let’s see this with an example. We are working on file “Program.cs”, here is the version list for that file. We are having latest version (1.1.2) of the file in workspace.

Version List

Now, we want version 1 in our workspace. So, we select version 1 and perform “Get”.

Get Older Version

And it gets version 1 into the workspace, as we see in below figure.

Got Older Version

Then we made some changes in the file (changes made on top of version 1) and we have committed the change to repository on branch. So, new version 1.2.1 will be created.

Committed Changes on Older Version

History Diagram

Parallel Development – Refresh CheckOut Status

In this post I will showcase how does “Refresh CheckOut Status” (and Recursive) help during Parallel Development or Concurrent Development.

What it does is – it refreshes the check out status of the file in Visual Studio workspace. To describe it other way – it fetches the latest status of the file in CA SCM repository, and accordingly refreshes it in Visual Studio. That refresh could involve -

1. If the file in Visual Studio (user1) is checked out, but latest version of the file in repository is normal (N – normal tag, not checked out), after “Refresh CheckOut Status” is performed it will show the file as normal (checked in – glyph) in Visual Studio Solution Explorer. Also, it will remove the file from “Pending Changes” window. “Pending Changes” window shows all locally changed files.
2. If the file in repository is checked out, it updates the glyph (icon) of the corresponding file in Solution Explorer to mark it as checked out. It adds the file in “Pending Changes” window. Also, if the file in repository is checked out by a different user (user2), it shows the “Exclusive Check Out” glyph beside the file in Solution Explorer.

“Refresh CheckOut Status – Recursive” – does the same operation not just on the selected file, but also on the children of the selected file.

Let’s consider the C# Windows Form Application “WindowsApplication1″.

User user1 opens his Visual Studio IDE and does not know if anyone else has checked out “Form1.Designer.cs” file. He tries to check out that file. But in repository the file is checked out by another user (user2).

Second CheckOut (user1) - Failed

 

Then he does “Refresh CheckOut Status” on that file.

Refresh CheckOut Status - User1

Let’s see the “Refresh CheckOut Status – Recursive” now. User user2 checkes in “Form1.Designer.cs” file, but checks out some other files.

Checked Out From Workbench - User2

Now, User user1 does a recursive refresh.

Checked Out From Workbench - User2 - Refresh - User1

Now, user2 checks in the checked out files. But user1 used Workbench to checkout some files. Now, same user user1 refreshes from Solution level.

Checked Out From Workbench - User1 - Refresh - User1

I hope this was useful.

Parallel Development – Synchronizer

What’s the role of Synchronizer during Parallel Development?

All my local projects and the solution file are under C:\LocalPathToSolution.

All of the above files are checked in to repository path \Repo\RepositoryPathToSolution

Well, it does a comparison of files and folders under this local path and repository path and represents the data in Synchronizer Window within MS Visual Studio IDE. During parallel development, this functionality is quite useful as it helps us to see if someone has made some changes to the repository under that repository path. Also, it shows what all changes I have made locally in my Visual Studio workspace. Is there a situation, where I and my colleague have changed the same file and my colleague has committed his/her changes to the repository already – Synchronizer has the answer and shows that as a conflict.

“Changes” could be anything, normal edit of a file or refactoring changes or even addition of a new project to the solution.

With respect to the local Visual Studio workspace, it shows the changes in the Synchronizer tree view as -

Incoming Change, Addition, Deletion, (Changes Towards Visual Studio, Changed in Repository)

Outgoing Change, Addition, Deletion, (Changes Towards Repository, Changed in Local Workspace)

Conflict (Changes in Both Local Workspace as well as in Repository).

There are additional operations (like, Commit, Update from Repository, Compare, etc) those are enabled in this Synchronizer tree. The Synchronizer Window has a list view showed in the right pane. It has a graphical view also showing the changes in Local Workspace and Repository for the selected item in tree view. The list view shows all the changed children items of the selected item in tree.

Let’s create a C# WindowsFormApplication (WindowsApplication1). Add the solution to CA SCM repository. Now, if you invoke “Synchronizer”, there will be no change in repository also, so it shows that information to the user (user1).

No Change, Synchronize

Now, user1 makes some changes in his workspace – added some files under solution and under the project. Also, he deleted one file ‘Program.cs’. Let’s synchronize now.

Local Changes Only, Synchronize

In the mean time, another user (user2) also started working on this solution in his own workspace from a different machine. He added a new project (WindowsApplication2) to the solution and committed to the repository.

Now, when user1 synchronizes:

Local And Remote Changes, Synchronize

In the Synchronizer Window, it shows all the local and repository changes at this time.

Incoming Outgoing Notation, Synchronizer

Parallel Development – Late Binding Mode

Late Binding mode provides more flexibility for Parallel Development compared to being in Online mode. One major difference is nobody needs to keep the file checked out in branch (e.g. 0.1.1(R)). So setting the correct context (CA SCM) part is delayed till the users commit their changes. Only when someone needs to commit the changes, it requires a CA SCM context (Package, Check In Process and other processes).

Let’s assume, CA SCM Administrator has helped initializing the creation of a project (CA SCM Project) and baselined the source code in that project. And it has the below structure:

====== Source Code Baselined ======

CA SCM Broker: BrokerMachine

CA SCM Project: ParallelDev

State for Development: Development

Check In Process: Check In on Branch and Trunk

View Path : \Repository\Source Code\Common

======= Pre-requisite Information ========

Solution File: Solution.sln  (under \Repository\Source Code\Common)

Install CA Software Change Manager client

Install the Visual Studio Plug-in for CA Software Change Manager

SCM Explorer: Available from “View -> SCM Explorer” menu in Visual Studio IDE.

======= Late Binding Mode – First Developer – user1 ========

User1 opens Visual Studio IDE and then opens SCM Explorer as being instructed. Clicks on “New Broker Connection”, provides login details and connects to CA SCM broker (BrokerMachine).

Navigates to CA SCM Project “ParallelDev”, and navigates till repository path “\Repository\Source Code\Common”. He finds the solution file “Solution.sln” in the list view in right pane.

Right clicks on the solution, and performs “Open Solution”. Wow! The solution is in his own machine now and it is open in his Visual Studio with managed glyphs (icons beside files in Solution Explorer).

Next important thing is – start working as I don’t need any context now.

User1 is least bothered about who else is working on which file this time. He started changing in several files.

======= Late Binding Mode – Second Developer – user2 ========

User2 opens the solution in his machine in Visual Studio IDE from CA SCM. The solution and all its files are shown as managed.

User2 also updated few files from the IDE.

======== Commit – Set Context ========

Before any of the users commit their changes, it requires a context (CA SCM), so let’s set the context. If you see, I don’t even have set the check out process this time. And for check in process, I have kept both the option Branch and Trunk enabled, so I will explain both the cases separately.

==== User1 – Context ====

Package: dev1

Check In Process: Check In on Branch and Trunk

==== User2 – Context ====

Package: dev2

Check In Process: Check In on Branch and Trunk

====== Commit – On Branch ======

If both the users are committing changes on Branch, chances of getting a conflict in local workspace is absent. Only when those branch versions are merged in CA SCM (using CA SCM Workbench), there it may create merged (M) tag versions, which we need to resolve and create a normal (N) tag.

====== Commit – On Trunk ======

What if both are committing on Trunk, now it may find conflicts (both started working on 0′th version of the file, both users have changed the same file from their own workspaces, and one of them has committed the change to repository on Trunk). So, second user has to resolve the conflict from within IDE. Only after that it allows to commit the change (conflict file) to the repository. In this case, users don’t have to resolve any merged (M) tag from CA SCM Workbench.

======= All Set Now! – Let’s Change Few Other Files ======

 

Parallel Development – Online Mode

When in Online mode, Parallel Development is fully under control of the underlying server’s support in achieving it. You have to design your processes (e.g. Check Out/In in Branch) in such a way that server itself allows checking out a file by multiple users at the same time.

Let’s assume, CA SCM Administrator has helped initializing the creation of a project (CA SCM Project) and baselined the source code in that project. And it has the below structure:

====== Source Code Baselined ======

CA SCM Broker: BrokerMachine

CA SCM Project: ParallelDev

State for Development: Development

Check Out Process: Check Out on Branch          (‘Concurrent Update’ on)

Check In Process: Check In

View Path : \Repository\Source Code\Common

======= Pre-requisite Information ========

Solution File: Solution.sln  (under \Repository\Source Code\Common)

Install CA Software Change Manager client

Install the Visual Studio Plug-in for CA Software Change Manager

SCM Explorer: Available from “View -> SCM Explorer” menu in Visual Studio IDE.

======= Online Mode – First Developer – user1, Package – dev1 ========

User1 opens Visual Studio IDE and then opens SCM Explorer as being instructed. Clicks on “New Broker Connection”, provides login details and connects to CA SCM broker (BrokerMachine).

Navigates to CA SCM Project “ParallelDev”, and navigates till repository path “\Repository\Source Code\Common”. He finds the solution file “Solution.sln” in the list view in right pane.

Right clicks on the solution, and performs “Open Solution”. Wow! The solution is in his own machine now and it is open in his Visual Studio with managed glyphs (icons beside files in Solution Explorer).

Next important thing is – set the correct context. So, right click on any file in Solution Explorer and select “Edit Context”. Set the following and Finish.

==== User1 – Context ====

Package: dev1

Check Out Process: Check Out on Branch

Check In Process: Check In

==== User2 – Context ====

Package: dev2

Check Out Process: Check Out on Branch

Check In Process: Check In

========= Check Out: Program.cs ==========

All set now. User1 checks out file Program.cs (checked out version 0.1.1(R), package – dev1).

User2 checks out the same file (checked out version 0.2.1(R), package – dev2).

User1 makes changes and checks in (version 0.1.1(N)).

User2 makes changes and checks in (version 0.2.1(N)).

======= Merge Changes =======

Open CA SCM Workbench.

Perform “Concurrent Merge” on package dev1. Creates version 1(N).

Perform “Concurrent Merge” on package dev2. If there is any conflict it will create version 2(M). Use Interactive Merge on the merged tagged version (2(M)) to resolve the conflict. It creates normal version 2(N).

======= And, you are done! ======

Version History Diagram in Parallel Development