QVCS Product Family Newsletter - September 2005

Publication date: September 1, 2005

Contents

• QVCS/QVCS-Pro 3.8.23 Build Available
• QVCS/QVCS-Pro 3.9 Open Beta
• QVCS/QVCS-Pro 3.9 Cache locking changes
• QVCS-Enterprise - Under the hood...

QVCS/QVCS-Pro 3.8.23 Build Available

The 3.8.23 build is a bug-fix build that you can download from:

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

Fixed Bugs:

• A couple of changes to make QVCS work well with SAMBA file servers.
• Fix problem with qput so it will behave as earlier releases for wildcard operations.
• Fix problem with qput so you can apply a label at checkin. This was broken in earlier 3.8 builds.
• Change temporary file naming convention so deletion of temporary files will not also delete important QVCS files in the case where the user has defined their temporary file directory to be the same as their QVCS executable directory.
• Increased the margins on reports.
• Fix problem with .ini files getting reset to have empty contents.

QVCS/QVCS-Pro 3.9 Open Beta

The QVCS/QVCS-Pro 3.9 beta is now available. The release is feature complete, and ready for wider testing. Take it for a spin to see how it feels. Our web site has the latest info and download links, and there is a separate forum section for beta topics.

Here's a brief summary of the changes in 3.9:

• Directory recursion within QWin.
• You can associate a named file filter with a specific project.
• You can copy an existing named file filter to create a new named file filter that has the same set of filters.
• Support for a new $Project$ keyword.
• Some usability tweeks (e.g. added keyboard accelerators, etc.).

In all, there were 580 changes made to 219 separate source code files for this release.

QVCS/QVCS-Pro 3.9 Cache locking changes

There are a few other changes coming in 3.9, along with the support for directory recursion within QWin.

One of those changes is 'under-the-hood', but bears commenting on, since it can affect the way you use 3.9.

In order to get decent performance for the recursion feature, I had to change the way the cache locks are handled. This change makes it important that you not mix running 3.9 with any earlier releases -- at least at the same time. (You can safely mix running 3.8 and 3.9 IF you make sure they never are running at the same time).

This proscription is similar to the one that still exists for running QVCS-Enterprise at the same time as QVCS/QVCS-Pro.

The other constraint that results from these cache locking changes:

ALL USERS MUST ALWAYS RUN QWIN FROM THE SAME SHARED DIRECTORY. If you work in a team environment, make sure to install QVCS into a shared directory that all team members can access, and make sure that all team members run their copy of QWin from that shared directory. If you fail to do this, you WILL get cache corruption problems.

If you're technically curious, read on.... if not, just skip to the next article.

First, a bit of background.

QVCS/QVCS-Pro are 'file-based'. This means that each separate copy of QWin3.exe has to figure out the state of all the files -- it cannot rely on a server to maintain that state. As the number of files under version control increases, the amount of time it takes to figure out all file statuses grows. Without a cache file, QWin would have to open each separate archive file (one for each file under version control), see if anyone had a lock on the file, etc., compare the workfile with the latest revision in the archive, etc. This produces an accurate status, but is also very disk intensive, and very slow. To improve performance for this activity, I introduced a cache file so that instead of opening a separate archive file for each file under version control, QWin could open a single cache file for each separate directory. The cache file holds summary information for each file in that directory so that status can be computed using the cached information along with the information the QWin obtains about the current workfile.

This approach works well if you need to only look at one directory at a time. With the introduction of recursion in 3.9, looking at only one directory at a time is no longer the norm. Some projects span many, many separate directories, and there is a separate cache file for each of those separate directories. For this feature to be of any value, performance had to be improved.

The approach I chose was to introduce a memory cache for the information that in the past had been stored in the cache file. (You may notice that QWin 3.9 uses a LOT more memory than earlier releases) The cache file still exists, but it is only read when QWin knows that it is different from the cache that it maintains in memory. The way QWin figures out that the cache file is different than the in-memory copy is to timestamp its reads of the cache file. If the directory containing the cache has changed since the cache was last read, then the cache needs to be read again. It was this new memory-caching strategy that forced the change in the cache-locking strategy.

In earlier releases, the cache lock file was located in the same directory as the cache file. To work with a cache file, QVCS would create the cache lock file, open it for write, then read and/or write the actual cache file, then close and delete the cache lock file. With the in-memory cache refresh strategy, using a cache lock file located in the same directory as the cache file would guarantee that any access to the cache file would update the timestamp on the cache file's directory, making the memory cache worthless.

By moving the cache lock file to a separate directory, the situation improves, since only actual changes to archive files located in the the cache/archive directory would cause a timestamp change on the cache/archive directory. The net result of this change is good performance at the expense of not being able to mingle the use of the 3.9 release with earlier releases.

QVCS-Enterprise - Under the hood...

When you install the QVCS-Enterprise server, there are several files in the qvcsBehaviorProperties directory that are worth knowing about. For this month, we'll take a closer look at the qvcs.extension.attributes.properties file.

The qvcs.extension.attributes.properties file that is included in the distribution has a lot of comments in it already. The file is just a simple text file -- for Java gear-heads, it's really a 'properties' file. The purpose of the file is to define the default QVCS attributes that a newly created file will be assigned. The basic idea is to have a specific set of QVCS attributes that make sense for each defined file extension.

For example, let's look at the html entry:

html=YES,NO,NO,NO,YES,YES,YES,NO,NO,NO,NO

As described earlier in the file, this translates to:

Check locks	Yes
Delete workfile	No
Expand keywords	No
Protect archive	No
Protect workfile	Yes
Journal file	Yes
Compression	Yes
Binary file	No
Automerge	No
No Compute delta	No
Latest revision only	No

If you wanted to change the server's behavior so that, by default, you enabled keyword expansion for newly created html file, you could edit the html entry in this property file to look like:

html=YES,NO,YES,NO,YES,YES,YES,NO,NO,NO,NO

If you have some other file extension that you use on a regular basis that is not yet defined in the property file, you would just add a line to the property file for that file extension, defining that QVCS attributes as appropriate.

Note that the values defined in this property file are only used:

• At archive creation time. After archive creation time, QVCS attributes are defined within each separate QVCS archive file. This means that changing an entry in the properties file WILL NOT affect the QVCS attributes of QVCS archives files that already exist.
• If the client has NOT defined what the QVCS attributes for the file will be. The QVCS-Enterprise client allows the user to separately specify (via the Add File dialog) what QVCS attributes for a newly created QVCS archive should be. Only if the user does NOT define those attributes will the QVCS attributes defined in this property file be used.