CA Harvest has made use of Microsoft's Source Code Control Application Programming Interface (API) since version 3.0. At that time, CA Harvest VCI used *.hp~ project files to store information about the source files under CA Harvest control. The plug-in was simple, and provided basic check in and check- out functionality, in addition to other supporting options. As the product has matured and evolved over time, the architecture has been retained - from the early Galaxy-based architecture (version 4.1.2) to version 5.1.1 and beyond. Even in CA Harvest r7.0, a fundamentally similar VCI was still present.

After the CA Harvest r7.0 release, many things changed.

The initial releases of VCI supported SCC API version 1.1, which, despite its widespread use, had limitations. It supported IDEs such as msdev 6.0 and .NET 2002. When .NET 2003 emerged, the integrated SCC API was updated to version 1.2. In addition, the API was updated again in version 1.3 to support Visual Studio 2005. VCI changed with these developments, providing us with an opportunity to update the VCI architecture.

The first release of VCI r1.2 became available as a separate plug-in for CA Harvest r7.0. This first release supported .NET 2003, followed by the CA Harvest 7.0 Patch 2 that included support for Visual Studio .NET 2005.

To retain the valuable functionality of VCI r1.1 to support IDEs such as PowerBuilder and Rational Rose, version 1.1 is still included in the new 1.2 installation. If an IDE attempts to log into CA Harvest using VCI, a dll (VciSccProxy.dll) determines which version to deploy and no user action is required.

How to Convert My Solutions from VCI r1.1 to r1.2

The recommended process is fairly simple. Both .NET 2003 and Visual Studio 2005 offer a Change Source Control dialog (see figure 2). In this dialog, you can either bind (if your solution is not yet under source control) or unbind (if your solution is already under source control).

To migrate a solution, perform an unbind to detach the solution from source control using VCI r1.1.

Note: The Disconnect option does not remove any SCC bindings and should not be used in this context.

After you perform the unbind, upgrade VCI to r1.2, open the same solution from disk, and perform a bind to attach the solution back to CA Harvest control. This will re-establish the SCC bindings (discussed later in this article).

Important! Only conversions using .NET 2003 are supported because Visual Studio 2005 has not been certified with VCI r1.1.

Considering this information, if you have Visual Studio 2005 solutions in CA Harvest VCI r1.1, we recommend that you try the migration in a test environment, which may work.

Note: For more information, see the VCI r7.20 or SP1 documentation. The instructions in previous documentation releases may not match the instructions in the VCI r7.20 version. However, you will be able to complete your tasks successfully using those instructions too.

Why You Should Use VCI r1.2

One reason why you should use VCI r1.2 is that .NET 2003 and Visual Studio 2005 use SCC API 1.2/1.3. Another reason is that the new VCI r1.2 works through the CA Harvest Software Development Kit, which provides quick and reliable access to the CA Harvest functions. Finally, VCI r1.2 does not use hp~ files. This should be good news to those VCI users who encountered file corruption in this all-important piece of early VCI architecture. After you migrate from VCI r1.1 to r1.2, you can safely get rid of these files.

New Features in VCI r7.20.5 / SP1

In addition to the Command Log, Package Explorer, Current Context, VCI cache, Harweb forms and other features already available in VCI r1.2, VCI r7.20.5 / SP1 now provides Create Package, Item-Level context and further support for offline development.

The Create package feature allows developers to create packages without having to use the CA Harvest Workbench. You can now execute the process from the Global Toolbar, the Set Context dialog, and from the Package Explorer.

The packages can be used on the item-level, meaning that each item in the solution can have its own context package - making emergency fixes much easier. In addition, you can click the Disconnect button to work offline, write code fixes when you are not in the office, and connect back to CA Harvest when you return to the office to synchronize your changes with the CA Harvest repository.

New Features in CA Harvest 7.1 SP1 HOTFIX 1

As a way of improving the way CA Harvest VCI handles concurrent development, we have added some enhancements to the HOTFIX 1 VCI code. These include a checkout dialog where the user can select checkout mode and version, and also provide the user with a button in History dialog, with which a previous version can be called to replace the current version in workspace. This resembles similar functionality in our Eclipse plug-in. Also, automatic solution file binding corrections and file property information improvements have been implemented. For more information on these additional enhancements, please see CA Harvest support pages at http://supportconnectw.ca.com/public/endev_ccc_lib_panv/harvest_supp.asp

Performance has been improved in CA Harvest VCI r7.20.5, especially in daily tasks such as Check-out, Check-in and Get Latest. Harvest 7.1 SP1, which includes the new VCI, also provides many generic performance fixes.

Additional performance improvements in VCI r7.20 and SP1 not represented in the previous figure include improvements for Close Solution and Package Explorer with large number of projects and packages.

There are, unfortunately, some limitations on the performance improvements. VCI integrates several products that work together. If a particular task appears to be working slowly in VCI, it may be the other product, rather than VCI, that is working slowly. For example, Open from Source may perform slowly with large solutions (dozens of projects and thousands of source files). This commonly happens because the IDE requires the project and solution files to be checked out separately first. The IDE then reads the contents of each project and the solution file to determine which files are under source control. After this happens, the source files are then checked out to the client location. Depending on the number of projects in the solution, the whole process may result in hundreds of executed CA Harvest SQL queries. As a result, the check out process performs much slower than with a single-project solution, even if the number of source files in both solutions is the same.

Source Control Binding impact on performance

Another related consideration is the number of separate bindings stored in the solution and project files. If the solution's projects are located in multiple places on your local disk, or on a shared network drive, the solution becomes non-hierarchical . This means that the solution's bindings (the location information) cannot be used for each project even if they are part of the same solution. This may result in a separate binding for each project. For each separate binding, VCI has to query the RDBMS to verify the view path, related source files, and so forth. The increased number of queries may result in poorer performance.

There are also other reasons why a non-hierarchical solution structure can cause problems. Multi-user concurrent development may be difficult with non-hierarchical solutions, as several different users will be opening the solution directly from source and making changes to files, or even adding new non-hierarchical projects or source files to solution. Merging and updating the single solution file in CA Harvest source control may become complicated. Visual Studio 2005 itself warns when adding a new project to a non-hierarchical location:

Figure 2: VS2005 SCC API warning when adding a new project to a location that is not under solution root

Therefore, when adding solutions and projects to Ca Harvest source control or binding to source control, we recommend that you try to use the solution's location (binding) for all projects, but understand that there may be situations where this is not strictly possible.

A way of checking if you have non-hierarchical projects or source file structures is to open the *.sln file in a text editor and search for section 'GlobalSection(SourceCodeControl)'. Any entries with the following structure would indicate non-hierarchical bindings:

\u0022Harvest\u0020context\u0022,\u0020/49/191/183/2/0/

String syntax:

u0022 is a unicode double-quote and u0020 is a space. The rest is CA Harvest context information, ie rdbms (oracle, mssql server) column values. In this case, 49 is the CA Harvest project id, 191 the state id, 183 working view ID and 183 View path id. The /2/0/ refer to the CA Harvest context checkin and checkout process ids.

Similar information is also stored in the MSSCCPRJ.SCC file. This Visual Studio file is created by IDE locally when adding to source or opening from source, and stores bindings for all projects and solutions. It should not be added to CA Harvest source control.

You can see the MSSCCPRJ.SCC binding information also in 'change source control' -dialog:

Select the solution file in this dialog. If a project is NOT highlighted in this dialog together with the solution file, it either does not contain bindings (= is not added to CA Harvest yet) or that its binding is different from the solution. In the above example, 'App2' has a different view path with haritems.itemobjid=2008 instead of 1970

This dialog is a very easy way to check which projects in the solution contain non-hierarchical bindings.

NOTE: When adding or binding a solution to CA Harvest, there is an option that controls how view paths are created. When using RegEdit.exe, look for the following key:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\SourceControl

(For .NET 2003, the path contains 7.1 instead of 8.0)

In the key, you will see several values related to MS IDEs. One of them, DoNotCreateSolutionRootFolderInSourceControl controls the solution root view path creation in the SCC repository. The default value is 0, which means that solution root folders are automatically created when adding or binding to CA Harvest. When you select your solution location in the CA Harvest repository, a view path folder with the solution name is created underneath the selected location. Any shared or common non-hierarchical folders are duplicated under this solution root. If you have shared or common non-hierarchical folders and you want to retain the original folder structure, you may want to change the registry entry value to 1 so that no solution root is automatically created. If you want, you can always create it manually as well.

Generic performance considerations

Some general considerations for improving the performance in VCI and CA Harvest include the following:

Raw processing power. The faster the server, the better performance.

Disk space, size of RAM, and Virtual Memory / SWAP space.

RDBMS tuning. Make sure the CA Harvest Repository is performing optimally. If you are using Oracle, consider generating statistics for all CA Harvest tables and making sure the indexing is fine.

Network performance and bandwidth. If you are using 512KB WAN, do not expect the same performance as with 1GB LAN.

Firewall, TCP/IP settings, and so on. Even the TCP/IP package size can be a bottleneck.

Other processes competing for resources. A full virus scan can slow down the system and cause file locking problems.

How Users Can Improve VCI Performance

Performance configuration does not stop at the system administrator or RDBA level. Every CA Harvest VCI developer can improve local performance even if the network is slow and SCC bindings are located in multiple places. VCI users should consider the following information to improve performance.

Use a larger VCI cache for large solutions. Instead of a default 5 or 300 seconds, set it to 3000.

Note: In the previous figure, the performance trade-off is that the item status is not locally refreshed until 50 minutes expires. If you perform a Refresh Status before the time expires, VCI will assume that the item status has not changed even if another user has just checked the same item out for update. As a result, the item icon will not indicate that another user has reserved the item. If you are not dealing with large solutions, we recommend that you keep the VCI cache at 5 or 10 seconds.

If not required, suppress the Checkout Group dialog (VCI r7.20 and SP1 only) by deselecting the option. With very large solutions, populating this dialog may cause some delay during checkout.

Open from source only to obtain the source files for the first time. After you have local copies of the source files, open the solution from disk and perform a Get Latest.

In the IDE, Only Build Startup Projects on Run. This will restrict background compiles for startup project and dependencies. It is not always necessary to compile every project in a solution when they have not changed.

Suppress automatic updating of 'Pending Checkins' view by renaming the following registry key. Do not destroy the gui id though, so that it can be easily renamed back if required. For example, simply add an underscore to it

By default, the 'Pending checkins' dialog is always opened in the background when VS2005 IDE is started. The information in this view is updated with every checkout and checkin, which can cause performance problems with large solutions. After renaming the above key, the 'Pending Checkins' dialog is only opened by the user manually.

Note that even after renaming the above key, if user does open the 'Pending Checkins' manually from IDE option View - Pending checkins, then the view will remain open in the background (even if closed!) until IDE is restarted again.

Restart your IDE after any settings or registry entries have been modified.

Make sure you have installed the most current CA Harvest patches and updates.

Note: These performance considerations do not guarantee that the VCI and IDE will immediately gain 100% performance improvement. When working with small solutions having, for example, ten projects and five hundred source files, you may not notice any performance improvement at all. With a fast server and LAN, you may only notice a few seconds difference even with much larger solutions.

The previous VCI and IDE settings may help with slower systems where every I/O transaction makes a difference. In a fast system, ten thousand RDBMS queries when opening a solution is not a problem. In a slower system, the same can be very slow indeed. On the other hand, do not expect your performance to improve dramatically if you have an old, obsolete NT box with a fragmented Oracle 8.0.1 database. Work through the performance basics first, upgrade your server, and then apply the previous VCI suggestions to improve your performance.

Note: The VCI documentation has been updated for r7.20, SP1, and .NET.

On the CA Harvest support web site, you will also find the latest CA Harvest Field Development Utilities and new VCI tools, including the SCCConsole that lets you switch between SCC providers and cleans up old bindings: