QVCS Product Family Newsletter - March 2006

Publication date: March 2, 2006

QVCS/QVCS-Pro: 3.10.6 Release Now Available
QVCS/QVCS-Pro: Using local QVCS/QVCS-Pro installs in a team
QVCS/QVCS-Pro: Cache changes for 3.10 Release
QVCS-Enterprise: Roadmap for the next release

QVCS/QVCS-Pro: 3.10.6 Release Now Available

The 3.10.6 release is available for download from the usual locations:

http://www.qumasoft.com/QVCSSetup.exe

http://www.qumasoft.com/qvcs.zip.

This is a 'free' update to users who have purchased their license within the past year. Users with older licenses will have to update their license in order to use this release.

The focus of this release is the addition of support for .dll based triggers (QVCS-Pro only). The other nice feature added in this release is improved support for checkout comments. There are more details available here.

QVCS/QVCS-Pro: Using local QVCS/QVCS-Pro installs in a team

Beginning with the 3.9.25 release, QVCS and QVCS-Pro now allow you to install the application locally, but have that local installation 'point' to a shared location for accessing the qwin.ini file and user .ini files. This change was required in order to get QVCS-Pro to work in a useful way with Visual Studio 2005, but it can be useful in other situations as well. For example, if you want to minimize network traffic, it helps (a little) to have QVCS installed locally, instead of on a file server -- loading the application from the local drive generates no network traffic.

The 'magic spell' to make this work is to create a qvcs.ini file located in the local directory where QVCS is installed. In that qvcs.ini file, there should be two lines that look like:

[Initialization] LicenseLocation=\\Qumadell\qvcs3.10

where you would change the value for 'LicenseLocation' so that it points to the shared network directory where your qwin.ini, user .ini files, and QVCS.License file are located.

When you launch the QWin3.exe located on your local drive, it checks for the existance of the qvcs.ini file. If it's found, it uses the value for LicenseLocation to tell it where to find qwin.ini, user .ini files, and the QVCS.License file. This also works for the command line utilities.

QVCS/QVCS-Pro: Cache changes for 3.10 Release

The 3.10.6 release introduces another change to the way QVCS uses the cache.

First, a bit of background. QVCS and QVCS-Pro are 'file based' products. This means that each separate copy of QWin that runs must separately read/write/update the QVCS archive files that contain a file's revision history. In order to guarantee that no two users are updating a given archive file at the same time, QVCS has a file locking scheme to guarantee serial access to the archive files. As a project grows in size, this method of separately accessing each separate archive file can be quite slow. To improve performance, especially for larger projects, QVCS 3.3 introduced the option of creating and using a cache file. The cache file (Q$QCache) is located in the archive directory and contains a summary of the revision information for all the separate archive files for the given directory. By using the cache file, QWin could 'scan' all the archive files in a given directory by opening and reading just one file (the cache file), instead of opening and reading all the separate archive files. Our measurements showed that use of the cache improved performance by a factor of 3.

In early releases, use of the cache was optional. This is no longer the case -- QWin and the IDE integration now always use the cache.

Because QVCS is a file based product, access to the cache files must be serialized, just like access to the indivdual archive files. For larger teams, this serialization of access to the cache files can produce a 'cache collision' error message.

In the 3.9 release, with the addition of support for directory recursion within QWin, the chances for cache collisions increased, especially for large projects.

The 3.10.6 release decreases the chances of cache collisions by using two separate kinds of 'locks' for serializing access to the cache file. For operations that are known to be read-only operations (navigating to a directory, or refreshing the screen for example), QWin acquires a read-only cache lock. The advantage of read-only cache locks is that they can be shared. This means that if one user already holds a read-only cache lock, another user will be permitted to acquire a read-only cache lock.

For update access to the cache, a 'write-lock' is required. These kinds of locks are identical to the kind of cache locks that were used with earlier QVCS releases. Write-locks collide with any other kind of lock, and guarantee serial access to the cache file (and archive directory).

The bottom line is that the 3.10.6 release should produce fewer cache collisions, and produce a better user experience, especially with larger teams.

QVCS-Enterprise: Roadmap for the next release

With QVCS/QVCS-Pro 3.10.6 out of the way, I can turn my attention to QVCS-Enterprise. The 'big' features on the roadmap for the next release:

Support for IDE integration with Microsoft SCC compliant IDE's.
Support for project level operations.
Support concurrent operation with QVCS and/or QVCS-Pro.

Of these two, IDE integration by far requires the most work. I haven't completely scoped the work required, but my current guess is that this next release won't be ready for testing until late May at the earliest.

I will need beta testers for this release, as there will be a lot of 'plumbing' changes in order to do it right. Beta testers in the past provided a lot of help in both identifying bugs, and in helping refine the actual product feature set. If you are interested in helping out with the beta, please let me know.