QVCS Product Family Newsletter - December 2005

Publication date: December 5, 2005

Contents

• Forum Poll: Your input needed
• QVCS-Enterprise: Release 1.2.10 Now Available
• QVCS and QVCS-Pro: Project Level Locking

Forum Poll: Your input needed

We're running a poll on the forum site. The question is simple:

How many files are in your largest QVCS project?

Please, take a minute to register on the forum site, and then cast your ballot so we can get a better notion of the typical QVCS project size.

You can get to the forum site here.

QVCS-Enterprise: Release 1.2.10 Now Available

The 1.2.10 release of QVCS-Enterprise is now available. This is a free update for users who purchased their QVCS-Enterprise license after November 30, 2004.

The focus of the release is on improved usability. The main frame window in the client application now has a more complete menu bar, and many common operations are available without having to use the mouse.

The release also adds support for ignoring case in filenames, and fixes a few bugs. You can get more details from our web site.

QVCS and QVCS-Pro: Project Level Locking

If you've used the 3.9 release to apply a project level label, you may have noticed that other users get locked out while the label is being applied. This is both a good thing and a bad thing.

The good thing is that this prevents other users from checking in any changes while the label is being applied. The bad thing is that it also prevents them from doing any other useful things with QVCS while the label is being applied.

(For ease of exposition, in the following I'll use QVCS as a shorthand way of referring to both QVCS-Pro and QVCS, since for the purposes of this article, they are identical).

Beginning with the 3.9 release, QVCS creates a transaction wrapper around all accesses to the QVCS cache files. (This same strategy was applied even earlier for the IDE integration). With recursion enabled, there is no way to predict the actual order that filenames will be traversed. As a result, the cache files have to be locked en masse while the action is applied. Only when the action is complete is the tranaction closed. The closing of the transaction updates the cache files, and releases any cache locks that were acquired to perform the operation.

The acquisition of the cache locks is 'lazy' -- meaning that the actual performance of the operation causes the cache lock to be acquired. QVCS does NOT make two passes through the file list, first to acquire the cache locks, and second to perform the operation.

The consequence of this cache locking strategy is that long running project level operations -- like applying a project level label -- will effectively lock out other use of the archives for the entire duration of the project level update operation.

A workaround would be to manually visit every directory of a project, and apply the label to each separate directory. This is not a recommended approach, since it would be very easy to miss a directory.