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.

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

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.

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

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 ======

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

Online mode means you are always connected to the CA SCM (Software Change Manager) server or rather broker. Any change that you make in the local workspace in Visual Studio is immediately reflected in the CA SCM repository. So, you check out a file to start working in it. Really good thing for someone who wants to ensure that the fellow developer has started working on something at certain date and time. Also, in certain situation it restricts two users from updating or modifying a single file. What will happen if for some silly reason you are far far away from that giant server! You’ve got to be disconnected, but this mode does not allow that.

As a developer I will be little bit biased towards Late Binding for the simple reason of its simplicity and flexibility. Moreover, it does not force me to stay connected 24×7 to that giant server that I just talked about a little earlier. What a relief, may be now I can disconnect from the server, take a nab, wake up and do some changes in code (of course from Visual Studio). When I come back near to that roaring server, I can connect back to it and commit all my code changes to CA SCM repository. New versions of the changed files are now created.

Make your choice!

Synchronizer Window is a really new thing in this arena. In parallel development or concurrent development environment, where many developers are developing concurrently, using this window in Visual Studio user can see what are his local changes and what are changes in CA SCM (Software Change Manager) repository. It shows the changes in both the sides (local, repository) in a tree view with notification of – Incoming and Outgoing changes and conflicts. Conflict is a situation where two developers have changed the same file from two different IDEs and one of them has committed the changes to the repository.

SCM Explorer Window is a miniature of the CA SCM Workbench. What that means is user can see the connected CA SCM Broker (server) node in a tree view within this window inside the IDE. If expanded the broker node, it shows all active CA SCM projects under the connected broker. User can browse thru following CA SCM objects in the tree view – Broker, Project, State, View, Package, Form, Snapshot, Version in View, Version in Package, Version in Snapshot.

Pending Changes Window shows all the local files those are changed (checked out, edited, renamed, moved, deleted) in local workspace from the IDE. From there user can easily make out which all files are modified locally (only, does not track repository file changes).

SCM Output Window displays all the output messages (generated by the plugin locally or from CA SCM server) in a well manner. It has the provision to categorize and display either error messages from a category (Error, Warning, Information Messages) or a combination of them or all of them. So if user is interested only at the error messages provision is there to display only error messages. If someone is interseted to see Error and Warning messages, it is easy to accomplish using this view.

Version List Window lists down all the versions available in CA SCM repository for a local file in Visual Studio IDE. User can select an older version of the file and get to the local workspace.

Binding issues occur as the plug-in keeps SCC information in Visual Studio solution and projects files. The problem of binding information getting obsolete at times, keeping and frequently updating binding information in those Visual Studio files – they are real nightmares. Moreover, when used in a parallel development environment, where many developers share the solution and project files – binding causes roadblocks.

Integrity is another concern from the perspective of data accuracy in Visual Studio workspace as well as in SCC repository. To understand this problem I will give a small example here. Let’s say, you have renamed a Visual Studio project file, so the solution file is also updated (As a solution file maintains the inventory of all projects under it). Now, if you are committing the changes to the SCC repository, both the changes must go together (1. Renamed project, 2. Edited solution). Likewise, if you are undoing the changes, both the changes must be undone together. That “changes must go together” or ”changes must be undone together” – is integrity.

The last major concern is performance, which I need not explain. It can be caused by many reasons, few of them are – limitations from SCC server, non-optimized client (plug-in) code, bottlenecks incurred by the SDK interface from the SCC provider, limitations from SDK interface from Visual Studio, etc. So as developers, we must know where to improve and which one to choose there.

This VSIP based Visual Studio plug-in has got rid of the first two issues and has shown huge performance improvements. It does not write a single bit of SCC information in Visual Studio solution and projects files. Integrity check is incorporated during commit and undo operations. Finally, because of the right choice of technologies, improvements in SDK interfaces and optimized business logic – performance of most of the functionalities have improved drastically.

So, one final statement – “Knock it, to believe it”.