Happy New Year! "Free Beer!"

QVCS and QVCS-Pro are now free (as in 'free beer'). The web site now includes a generic license file (good for 100 concurrent users) for either product... See the download page to get your hands on one of the generic license files. Anyone can now use the latest release of QVCS or QVCS-Pro for free.

I also adjusted the price of QVCS-Enterprise -- it's now $39/user; down from the $69/user price of last year.

With my full-time job, I just haven't had the time that I would like to put in to product development -- so to be fair to customers, I decided to drop prices to better reflect my perception of the value add that I'm providing -- with QVCS and QVCS-Pro priced as 'loss-leaders' to help introduce folks to the QVCS product family.

Do these price changes mean that I'm giving up on product development? No... with the caveat that I have stopped active development on QVCS and QVCS-Pro. I remain comitted to all three products, but my current development efforts are exclusively focused on QVCS-Enterprise.

Please let me know if you have any questions.

QVCS-Enterprise 2.1.24 release now available

A new QVCS-Enterprise release is available. It's a minor release, so is a free update for anyone licensed for the 2.1.23 release. Details are available here. 

QVCS-Enterprise admin problems using JVM 1.6.0_29

The QVCS-Enterprise admin tool suffers from the same problem with JVM 1.6.0_29 as the client application. You can get it to work using a similar workaround. Like the client application, this must be done 'by hand':

1. On the machine where you want to run the admin application (admin.bat or admin.sh), find the qvcsProjectProperties directory. It should be beneath the directory containing the admin.bat file.
2. In that directory, there will be a file names qvcs.servername.your server name.properties.
3. Edit the QVCS_SERVER_ADMIN_PORT line to read:
   QVCS_SERVER_ADMIN_PORT=9888
4. Edit the QVCS_SERVER_ADMIN_TRANSPORT line to read:
   QVCS_SERVER_ADMIN_TRANSPORT=RawSocketProxy
5. Save your edits.
6. Make sure that your firewall (if you have one) has port 9888 open on the server.
7. Restart the admin application. It will now use a non-SSL connection to the server.

QVCS-Enterprise client problems using JVM 1.6.0_29

It looks like Oracle has done something with the 1.6.0_29 JVM release that breaks the way QVCS-Enterprise uses anonymous SSL. I haven't had the time to dive into details, but wanted to take a moment here to describe a workaround.

I suppose it's worth mentioning too that QVCS-Enterprise will not work as a Windows service on Java 7 -- the service wrapper that I use isn't compatible with Java 7 (the workaround for that is to use Java 6)... anyway, on to the workaround.

This has to be done 'by hand':

1. On your client machine, go to the directory where the client application is installed. Beneath that directory, there will be a qvcsProjectProperties directory.
2. In that directory, there should be a file named qvcs.servername.your server name.properties.
3. Edit the QVCS_SERVER_PORT line to read:
   QVCS_SERVER_PORT=9888
4. Edit the QVCS_SERVER_TRANSPORT line to read:
   QVCS_SERVER_TRANSPORT=RawSocketProxy
5. Save your edits.
6. Make sure that your firewall (if you have one) has port 9888 open on the server.
7. Restart your client. It will now use a vanilla (non-SSL) connection to the server.

An alternate workaround would be to revert to an earlier release of the JVM on the client.

Note that if you use the client application to edit server properties, it will 'automatically' reset the connection to be secure. So if you change the server properties, you'll have to follow the steps above again.

In the next major QVCS-Enterprise release -- support for 'translucent' branches

I've been working to add improved project level branch support to QVCS-Enterprise. I haven't finished yet, but have gotten far enough along to describe what I've come to call 'translucent' branches.

Before defining a translucent branch, I first need to define what I mean by the term 'project level' branch.

QVCS-Enterprise already supports file level branching. This is useful for applying a patch to an individual file, or some small set of files: Suppose you've created a release, and have applied a label to all the file revisions that compose that release. You now discover that you need to patch that release. In the existing product, you would duplicate the existing label, and then check out the files you need to change using that label, make your changes, and then check those changes back in, making sure to apply the new label to the changed files. You could subsequently perform a build using that new label to define the set of revisions that will compose the new, patched release. The file level branching would possibly be used when you checked in your changes in the case where the changed file had revisions newer than the revision associated with the release label. i.e. when you checked in the changes that composed your patch, a file level branch would have been created if any of those new revisions' parent revisions were not the tip revision of the respective file... (sounds complicated).

The goal with project level branching is to make all this label management stuff 'automatic', and much less prone to error.

The long term plan is to support two different types of 'Project Level' branches: Translucent Branches (a.k.a. Feature Branches), and Opaque Branches (a.k.a. Release Branches). Support for Translucent Branches will appear first.

So what is a Project Level branch, and more particularly, what is a Translucent Branch? To answer, I'll provide a description of its 'behavior' -- i.e. the typical use case that supplies the motivation for having a feature like 'translucent branches'. In the very simplest case, imagine you have a software based product to which you want to add several separate new features. Before starting the development of these features, it's not clear how long they will take to develop, but it is clear that it has business value to be able to add them to the product release as soon as you can. In order to do this, you'd like to have one developer (or team) begin work on feature A, and a second developer (or team) begin concurrent work on feature B. Meanwhile, there is maintainance work ongoing for the base product. With translucent branches, you could create a translucent branch for feature A, a second translucent branch for feature B, and perform the maintainance work on the trunk. If you set up things this way, all changes checked in on the trunk (the small maintainance changes) would automatically flow down to the feature A and feature B translucent branches. Developers on feature A and feature B would see the changes on the trunk without having to do anything more than a 'get' for those files that show up as 'stale'.

Meanwhile, feature A and feature B developers could be checking in changes on their respective translucent branches, and those changes would not be visible to the trunk, or to the other feature's translucent branch. When feature A is complete, the feature A developer would just 'promote' their changes to the trunk, and QVCS would automatically merge their feature A edits onto their trunk workfiles. The user would then verify that their feature edits had been merged successfully before checking those changes into the trunk. Once feature A's changes had been checked in to the trunk, those changes would automatically become visible to developers on the feature B branch. It's because checkins on the parent branch are automatically visible to any child branches that I'm calling these translucent branches -- because changes on the parent branch are immediately visible to the child branch.

At this point, I've got the 'happy path' coded and will be able to begin using translucent (aka feature) branches to add support for the additional non-happy-path use cases. This will take quite some time still -- but the major pieces are now in place.

QVCS-Enterprise: Label based views, RIP

I've decided to remove support for label based views in the next major release of QVCS-Enterprise... This release is still many months away, but I thought I'd let you know sooner rather than later so that if you've come to rely on this feature, you'll be aware that the feature will be retired in the next major release. This means that both read-write label based views and read-only label based views will no longer exist.

The workaround to using label based views is to simply work on the Trunk, and use labels and file filters to work with only those files that have a given label. It is a bit klunkier than label based views, but it will work.

The 'replacement' for label based views will be new support for project level branching -- both for 'Feature' branches, and for 'Release' branches... about which I'll write more as I get closer to code complete for the next major release.

QVCS-Enterprise 2.1.23 release now available

A new QVCS-Enterprise release is available. It's a minor release, and consequently is a free update for anyone already licensed for the 2.1.22 release. Details are available here.

I'm continuing to make slow progress with the next major release. It's main new feature will be support for what I'm calling 'Translucent Branches'. Translucent Branches might be better named 'Feature Branches'. I'll elaborate further on how they work in a separate entry here as I get closer to code complete.

Those of you paying attention will notice the fall off in release activity here as well as fewer blog entries as well. The primary explanation is that the hope of continuing Quma as a full-time effort has bumped into economic reality -- I wasn't making enough on Quma to pay the bills, so I've returned to the work force as a full time employee elsewhere. This is not a new circumstance for Quma -- for most of its existence it has been a part time effort (I was full time on Quma only from 2005 through 2007).

My day job (still in software development at a large US corporation) convinces me that there remains a niche for QVCS, in spite of the growth of open source alternatives. My cost structure is very low, and there remain some market segments where QVCS is a better fit.

QVCS-Enterprise 2.1.21 bug fix update now available

I just uploaded a maintenance release for QVCS-Enterprise. It fixes several problems that have turned up since the 2.1.20.2 release described here. 

The one new feature in this release provides a rudimentary hilighting of the changes on a 'replacement' line in the built-in visual compare tool. I say rudimentary because the algorithm for finding the beginning and ending of the highlight region is as simple as it gets: it compares the two lines character by character and begins the highlighting at the first characters that differ. The end of the highlight region is determined in a similarly simple way -- it starts at the end of each respective replacement line and defines the end of the highlight region to be the last matching character of each respective line. The goal is to provide some simple visual queue so your eye is drawn to where on the replacement line the lines differ. It usually works in a useful way, but it's not bullet proof and seems to occasionally produce inaccurate highlighting.... but it's better than nothing.

On a separate note, I'm continuing to make slow progress on what I'm thinking will be either the 2.2 or 3.0 release of the Enterprise product. The end is still a number of months away -- as in, the end is not yet in sight.

QVCS-Enterprise 2.1.20.2 now available

Oops. I introduced a major defect (a.k.a. bug) in the 2.1.20 release that is now fixed in the 2.1.20.2 release. If you downloaded the 2.1.20 or 2.1.20.1 builds, you'll need to update to the 2.1.20.2 build in order to be able to define new projects. The downloads are available from the usual location. 

QVCS-Enterprise 2.1.20.1 now available

Oops. I forgot to make a change in an ant build script which means the 2.1.20 build does not include the new client API classes.... So there is now a 2.1.20.1 release that does include the client API classes (in the gui_out.jar jar file). You can download it from the usual www.qumasoft.com/downloads.html download page.

QVCS-Enterprise 2.1.20 Release now available

I just posted the 2.1.20 release. You can read more about the changes here. This is the first release to include support for a client API -- which allows you to write a Java program that can query the QVCS-Enterprise server for information about the projects and files that are version controlled by the server. The client API javadocs can be seen here. 

Another QVCS-Enterprise beta...

I just posted another beta (2.1.19.2). You can download it here. This build fixes some issues I found in 2.1.19.1 -- in particular in the SCC IDE integration .dll. I've now tested this IDE integration with Visual Studio 2003, 2005, 2008, and Altova's UModel product. Things are looking good for the 'official' release on February 28.

Just posted a beta for an upcoming QVCS-Enterprise release

I just posted a beta release (2.1.19.1). You can download it here. The beta is a preview of what will be in the 'official' 2.1.20 release which should be out at the end of February.

This is sort of a maintainance release -- though it includes one fairly major addition: support for a client API. The client API allows a vanilla Java client to access information from the QVCS-Enterprise server so that you can create your own application to display information about the files that are version controlled by the QVCS-Enterprise server. This first release of the client API is just a 'look don't touch' kind of API -- the user of the API can look at what's on the server, but they cannot make any changes to what's there.... so it's a read-only kind of interface.

The other 'feature' in this build is support in the SCC (SCC IDE integration) .dll for the 'get all' and 'get recursive' area of the Microsoft SCC spec.

All the other changes are bug fixes:

• Rework of the checkin dialog so it displays correctly in non-US locales.
• Fix the view revision feature so it works correctly for workfiles larger than 10 megabytes.
• Fix the SCC visual compare command line so it works correctly on Vista and XP machines.
• Fix an SCC thread exit issue.

The beta is pretty high quality -- I'm using it here, so feel free to give it a spin. The simplest way to do that is to shut down your server, then just replace your existing server_out.jar jar file with the server_out.jar jar file contained in the beta .zip file.... then just restart your server. Switching back to an earlier build works the same way -- just replace your server_out.jar with the one associated with the build that you want to use.

In the pipeline after the 2.1.20 release (barring some emergency release) will be the 2.2 (though I may rename it to 3.0) release. The 2.2 release will have much improved view/branch support. It's been in progress for a while, and I can't predict its release date. I'll definitely have a beta period for it, as it includes a lot of new code and functionality.

QVCS-Enterprise 2.1.18 Release now available

I just uploaded the bits for the 2.1.18 release of QVCS-Enterprise. Find out more here. 

Year-end QVCS-Enterprise release

I'll be publishing a year-end release of QVCS-Enterprise in a couple of days.

This release adds a several usability improvements:

• You'll be able to change the font size used in the client application (within reason).
• You'll be able to skip the login dialog. The paranoid should not use this option, since it stores your password on the client hard drive, but for many users, this will be a handy way to improve the startup experience.
• The client will now automatically 'naviagate' to the directory that was last selected when you exited the client application.

The current plan is to publish this 2.1.18 release on December 28.

QVCS-Enterprise 2.1.16 Release now available

I just posted the QVCS-Enterprise 2.1.16 release. Details are available here. 

Next QVCS-Enterprise release (2.1.16) coming soon...

The current plan is to publish the 2.1.16 QVCS-Enterprise release on September 28.

The main focus, as noted earlier, is improved ant support. I've gone ahead and added support for most other operations so that you'll be able to get, label, checkout, checkin, lock, and unlock files at the project level, the directory level, and the individual file level. You'll also be able to restrict the operations to only those files that match a given file extension. You won't be able to add any files to version control, nor will you be able to perform administrative operations -- like change a file's attributes, or modify a revision description, etc. But with these added operations, you should be able to script most of those kinds of things you need to do for automating your builds.

This build will also have some bug fixes, and some cosmetic usability improvements.

Work in progress for next QVCS-Enterprise release...

I'm wrapping up work on the next QVCS-Enterprise release. It will have a few fixes and a few new features. The bug fixes are for corner cases -- for example, the client application has a bug where it will show an enduring hour glass if a user who lacks the privilege attempts to set the attributes on a file.

On the feature front, the main focus in the upcoming release is improvements in the ant task, including support for checkins. Along the way, I added the ability to limit the operation to a single directory, or a single file. As a result, the ant task provides the ability to do most of the things you need to do... The only big thing missing is support for the checkout operation. I may go ahead and add that just to make things more coherent and complete.

This next release will also include a minor change in the SCC implementation that will make things easier for PowerBuilder users.

I don't have a prospective release date for this one yet, but it will be sooner rather than later -- my guess is it will be out before the end of September.

QVCS-Enterprise 2.1.14 Release now available

I just posted the 2.1.14 release. As noted before, the 'big' feature add in this release is integrated support for merge.

Merging is useful in the concurrent edits style of version control -- where you don't lock a file, but just begin to edit it, and assume that (usually) no one else will edit the same file at the same time. If someone else does happen to edit the file, the first one to check in their changes wins -- er, I mean, the first person to check in their changes won't have to bother with a merge.... but the 2nd (or subsequent) person to checkin their changes will have to merge their edits with those of the first user before QVCS-Enterprise will allow you to check in your changes.

I've tried to make it easy to use -- but suggestions for improvement are welcome.

This is a free update for users whose license is less than 1 year old. Others with older licenses will have to purchase a license update in order to use this release.

Enjoy.

Upcoming QVCS-Enterprise release

I'm putting the finishing touches on the next QVCS-Enterprise release. The 'big' feature is added support for merging files. The build includes a non-visual merge that will silently merge the two separate edit streams into a common ancestor file and a visual merge tool that gives you finer control of the merge. The latter visual merge tool must be used if there turn out to be any collisions between the respective edits. (A collision occurs if both decendent files try to alter the same line(s) of the common ancestor file).

The build also includes change bar indicators on the visual compare tool (and the visual merge tool). The change bar shows a quick summary of where the changes in a file are located, and is pretty common in visual compare and visual merge tools.

The release date is June 30 so I'll probably have time to put in a few other minor changes.

Merge and visual merge

I'm getting around to adding the file level merge feature to QVCS-Enterprise. The goal is to make it drop-dead easy to use -- which can be a challenge for merge, especially when there are collisions... and I guess that's one of the things that has led me to put it off.

In any case, I've decided to go ahead, and already have a non-visual merge working. The non-visual merge works silently in the case where there are no overlaps, and fails (as it is supposed to!) in the case where there are any overlaps. The idea is that a visual merge will be required in the case where there are overlaps. A merge will only be attempted on a file that has a status of 'Merge Required'.

No predictions yet on how long it will take to complete... The non-visual merge went faster than I thought it might. I expect the visual merge will take a while longer, if only because it will require some usability after I get things roughed in.

QVCS-Enterprise 2.1.12 now available

I just posted the 2.1.12 release of QVCS-Enterprise. This release cleans up a few bugs, and adds one nice little feature -- a 'Show in containing directory' menu option on the file context menu. When you have recursion enabled and have lots of files, it is sometimes difficult to see exactly where in the project directory hierarchy a given file might be located. With this new feature, all you have to do is select the file (with recursion enabled), then select the 'Show in containing directory' context menu, and the client will automatically navigate to the specific directory that contains the file... a nice little usability touch.

Details on the fixed bugs are available here. 

Enjoy.

QVCS-Enterprise 2.1.11 now available

I just posted the 2.1.11 release. You can download the bits here. 

Details on the changes in this release are here. 

UPDATE: Fix link typo.

QVCS-Enterprise 2.1.11 to be published on Nov. 30.

I'll be publishing a 2.1.11 QVCS-Enterprise release this Friday (November 30).

This is a mainly a 'bug fix' release to clean up some issues discovered in the 2.1.10 release:

• Fix problem with 'checked in before' and 'checked in after' file filters.
• In built-in visual compare tool, pay attention to the 'ignore case' setting.
• Fix bug that prevented the deletion of a project that only had the 'Trunk' view.
• Fix a null pointer exception that occurs when trying to apply or remove a label from a file in a project that has just the 'Trunk' view.
• In the IDE integration .dll, make sure to delete the workfile at checkin time if the 'delete workfile' QVCS attribute is enabled.

The one 'feature' change for this release:

• Add the module description to the beginning of the information displayed in the 'Revision and Label Info' pane.

It always happens with a new release...

Whenever I publish a new product release, I get bug reports that point out problems that have existed for a long time. I suppose this is partly due to the closer scrutiny that a new release gets as users test it to evaluate whether it's worth their time or not. In any case, there are 2 problems that the new 2.1.10 release of QVCS-Enterprise has brought to light:

• In the 'checked in before' and 'checked in after' file filters, things work fine immediately after defining a filter collection that uses either of these two filter types; but fails with a null pointer exception if you try to use that filter collection after restarting the client application.
• In the built-in visual compare tool, the 'ignore case' flag was always ignored... i.e. while you could request that the visual compare ignore case in the compare, it would never ignore case.

Both of these bugs are now fixed in the code base, and the fixes will appear in the next build.

QVCS-Enterprise 2.1.10 Release Available

I just posted the first 'official' QVCS-Enterprise 2.1 release. You can download it from here. 

It has just a few cleanup changes since the 2.1.9.4 Release Candidate:

• I finally got the code in to put up a busy indicator when you change the column sort order.
• Changed the sort order for the revision information shown for the Read-Only label based view so that the revision information is displayed (like the Read-Write label based view) so that the view's tip revision sorts to the top of the list of revision information. This change is more important in those cases where the view's tip is on a branch instead of the Trunk.

For those of you paying attention, this release has been under contruction for a long time. It represents a lot of work -- 1577 changes across 559 different files. The source and documentation for this release is composed of 1126 separate files.

Upgrading to this release is pretty simple: Just shutdown your server application, and replace your existing server_out.jar file with the one found in the new qvcse.zip file. Restart the server, and you should be good to go... clients will get updated 'automatically' as they login to the new server.

The server does have to generate some meta-data the first time it runs -- so this could make startup the first time slower than usual -- but after that meta-data has been created, startup performance should be similar to what you've seen in earlier releases.

QVCS-Enterprise 2.1.9.4 Release Candidate Available

I just posted the 2.1.9.4 build.... It's good enough to be a release candidate -- it has some fixes for upgrading from QVCS/QVCS-Pro archives, as well as some other bug fixes related to the new view support, etc. You can download it from here. 

I have some minor documentation changes that didn't make it into this build, but it is otherwise 'code complete' and in pretty good shape. Please give it a try.

QVCS-Enterprise 2.1.9.3 Beta Now Available

I just posted the 2.1.9.3 beta for the upcoming QVCS-Enterprise release. This release also includes the IDE integration piece as that now works and has been updated to work with the new 2.1 features, including support for views.

The remaining area that needs work in this build: directory level operations (i.e. get and label) do not work for non-Trunk views. My plan is to disable directory level operations for views for the 2.1 release, but this beta still has some rough edges in that area of the client application.

This beta reworks the way file renames and file moves are handled so that things are more likely to behave in ways less surprising to users. In the earlier beta, if you moved a file (via drag-and-drop), the associated workfile would also get moved on someone else's workstation -- not good. The same would happen with a file rename operation. This beta fixes that so that the workfile will get moved or renamed only on the workstation that requested the move or rename. Other workstation workfiles are not affected.

Things are getting pretty stable, and the actual 2.1 release will get published soon after I complete the cleanup of the directory level operations for non-Trunk views.

QVCS-Enterprise 2.0.22 Release Available

I posted QVCS-Enterprise 2.0.22 earlier today. It has several changes for users who didn't want to wait for the upcoming 2.1 release (which is on track for a late September release date). The changes are described here. 

If you are upgrading from an earlier 2.0 release, the simplest approach is to:

1. Download the 2.0.22 release from here.
2. Shutdown your existing server application.
3. Exit any IDE's that use the IDE integration feature.
4. Copy the server_out.jar from the 2.0.22 download .zip file so that it replaces your existing server_out.jar file.
5. Restart your server.

Your clients should then reconnect to the server in order to get 'automatically' updated. Note that in order for the IDE integration .dll to get updated you need to login to the server using the client application (gui.bat).

QVCS-Enterprise 2.1.9 Beta Now Available

I just uploaded the first beta of the upcoming 2.1 release. You can get a copy here ... look for the beta download after the standard QVCS-Enterprise download.

This 2.1.9 beta release has all the major features that I want to include in the 2.1 release -- we've been using early versions of the 2.1 release internally now for several months.

As noted earlier, the big deal in this release is support for "views".

Things remaining to be done:

• Support for directory level operations from within a view. The workaround is to enable recursion, and select all the files in the view that you want to work on.
• Complete the work to get the IDE integration feature complete (i.e. support for file rename).
• Support for undelete so you can easily move a file from the cemetery back to where it came from (provided you have the proper privileges).

I also added a new forum for discussion of this beta. You have to login to the forums  in order to see the new forum... Becoming a new forum member is bit tedious because I have to filter out all the potential forum spammers.

Please do not use this beta for production use. A safe way to test this beta with your current archives is to create a copy of your current server directory tree (the directory where server_out.jar is located), then in that copied directory, replace the old server_out.jar with the one from the 2.1.9 release. You'll then need to manually edit all the qvcs.served.project.... property files located in the copied qvcsProjectProperties directory so that the archive location and reference location point to the alternate copied location instead of your production location. If the test server is running on the same machine as your production server you'll also probably want to change the server.bat in the copied directory so that the test server uses a different set of ports than those used by the production server.

Please post issues or comments on the forum, or send me e-mail. (jimv at qumasoft dot com).

Understanding Views

We'll soon be publishing an early beta for the upcoming 2.1 release. I don't want to commit to a date -- I've not been very good at predicting those lately. In any case, the big new shiny thing in 2.1 will be its support for 'Views'.

QVCS-Enterprise 2.1 will support 4 different kinds of views:

1. The 'Trunk'
2. Read-only date based views
3. Read-only label based views
4. Read-write label based views

The 'Trunk' view is the default view and is identical to what exists in the current 2.0 product.

The read-only date base view is described in this blog entry.

The read-only label based view is similar to the read-only date based view except that is uses a label to anchor the view instead of a date. You use this kind of view to see what a project looked like when a particular label was applied. You might use this kind of view to perform a build -- just create the label based view, assign a location for the view's workfiles, do a 'get' on the files of the view, and -- poof, you now have a workfile directory tree that matches what the project looked like based on the view's anchor label. As a read-only view, you are not allowed to make any changes to the files in the view, but it is a handy way to recreate what a project looked like at some particular label.

The read-write label based view is similar to the read-only label based view except you are also allowed to checkout and checkin revisions -- with some limitations: you are only allowed to work on the view's 'tip' revisions. QVCS-Enterprise will handle the details 'under-the-hood'. This kind of view is ideal for performing patches to a labeled release: create the read-write view based on the label, assign the workfile location for the view, get the files to that workfile location, and then make your edits (checkout/checkin) as needed in order to patch that labeled release. Once you are happy with your changes, apply a new label to the result, and then do a build based on that new label.

One constraint I've imposed with label based views: you are not allowed to move the anchor label of a view.... i.e. if there is a label-based view that uses label "2.1" (for example) as its anchor, then you are not allowed to apply or remove the "2.1" label from any files on any view, including the Trunk.

Views are a big deal -- and getting them implemented has been a lot of work. You have to look at products that cost a lot more (e.g. Starteam, MKS Source Integrity) to find this kind of feature. For later releases, views will serve as the foundation needed for some other cool features.

Another 2.1 milestone

I passed the next milestone for the QVCS-Enterprise 2.1 release: I can now create a read-only label based view. Two down, one to go... but the remaining one (a read-write label based view) is the most difficult.

QVCS-Enterprise 2.1.6 Technology Preview available

I just posted the 2.1.6 release. This is a technology preview only; it is not meant for production use... i.e. it is not feature complete and is missing some key features. DO NOT USE IT FOR PRODUCTION USE!

Now with that warning out of the way, I'd still like you to take a look at it to get a taste of what will be in the official 2.1 release -- which now looks like won't be ready until July or so. The biggest piece of work in this release is addition of support for file rename, and file move, combined with support for 'views'.

You can download the 2.1.6 technology preview from the download page. 

File rename, and file move are pretty easy to understand. The latter you get via drag-and-drop. I still have some tweeking to do on handling the drop target code, but if you are gentle in the way you drag-and-drop a file onto a different directory, things will work as expected.

View support is a bit more involved to explain... partly because it doesn't really have a direct analog. The kind of 'view' supported with the 2.1.6 release is a 'read-only' date-based view. When you create a view (by right clicking on a Project), you get to define the date that defines the view. Given that date, the view will display what the project looked like at that date/time. Because of the way it works, the earliest date you can use is the install date of the 2.1.6 release. In any case, the view will show you the Project as it was at that given point in time -- all filenames and file locations will be the filename and file location that was in use at the given time.... files that were deleted after the given date/time will show up, etc. It's like a time-machine.

Other changes for 2.1.6 include:

• Support for directory delete. A privileged user can delete a directory (using the client application) if the directory is empty and the directory has no subdirectories: right click on the directory name and choose the 'Delete Directory...' option from the context menu.
• Improved granularity of the authorization model. Use the admin tool for this: select a server node in the admin tool, and then choose the new Roles/Maintain Server Roles... menu option.

The remaining work for 2.1 is tricky... so it's hard to predict when I'll have it ready for beta.... but beta is the next step. After the beta wrings out the bugs, I'll publish the production release.

UPDATE: Added link to download page.

Obsolete will be Obsolete

No, I didn't make the change to the way obsolete files will work in QVCS-Enterprise just so I could use topic heading above....

Currently, in QVCS-Enterprise, when you 'delete' a file, the server just marks the associated archive file as 'obsolete', and then the client deletes the associated workfile.

In 2.1, this behavior will change -- and the concept of 'obsolete' files goes away. The new behavior will remove the archive file from the server's archive directory and move it to the archive 'cemetery'. The client application then deletes the associated workfile. If you need to do anything with the deleted archive, you'll need to create a 'view' that uses a view date that preceeds the date when the file was deleted.

This change is needed in order to implement the boundary use case described here. It also has a more coherent feel than the previous implementation. I've completed the coding for moving the deleted archive to the 'cemetery'. I still have to go through the rest of the refactoring to remove all code that deals with obsolete files -- since that code is now obsolete.

Back from Austin

We're back from a spring trip to Austin, Texas. Spring is a good time to visit Austin -- though I could have done without the tornado watches we endured on our final night in town. We stayed at the Brava House Bed and Breakfast. It's a superb location in a quiet neighborhood just minutes from downtown. The 6th street music scene is a long, but pleasant (1.5 miles) walk. The new marquee Whole Foods market is just a few blocks away, and other eateries are just as convenient. We had a great time exploring Austin, and the surrounding 'Hill Country' area of Texas. Summers there are brutal (all the local admit this to be the case), but this time of year, the weather was perfect.

Austin has Verizon broadband wireless coverage, so it was easy to keep up with e-mail and tech-support issues...

Now it's back to work on the QVCS-Enterprise 2.1 release. I've made the transition internally to using the new 2.1.4 release. I won't be making it public as it is still missing some key features (file delete, directory delete, directory rename, and directory move); but it does have the skeleton of views implemented, and I want to get some mileage on that before the public beta. I want to get file delete implemented before making anything public -- and for that, my current thinking is I'll have a 'technology preview' before the beta. The 'technology preview' will not be feature complete, but it will have the view stuff in place. I'd like to get some user feedback on 'views' sooner rather than later. Will users see it as confusing, or intuitive?

Stricter QVCS forum access

If you want posting access the QVCS support forums (http://qumasoft.ipbhost.com/ ), you'll need to jump through more hoops than in the past (Users who are already forum members won't see any change). For reasons that defy my understanding, QVCS support forums have undergone a sustained spam attack from folks who either want to waste my time (which may be their intent), or have some wild misunderstanding of what kind of message traffic I will allow to appear on a Quma support forum.

If you want to become a forum member, please drop me an e-mail (jimv at qumasoft dot com) as forewarning so I can let your membership application go through. If you are a registered user of any QVCS product, you'll just need to provide your registration ID. If you are not a registered user (why not?), then I'll be happy to let you on the forum if you can persuade me that you are not a bleep bleep spammer.

QVCS-Enterprise 2.1 progress...

I've passed a major milestone on the road to the 2.1 release: I can now create a 'read-only' date-based 'view' that works (there are still a lot of details that remain). This kind of view, the simplest of the new support for 'views' means that you'll be able to use QVCS-Enterprise as a time-machine to see what things looked like at some point in the past... including file renames, file moves, etc. I focused on getting this type of view implemented first because I figured it would be the easiest, and would help me better understand what would need to go into the other types of views that I want to support: a 'label-based' read-only view, and a label-based read-write view.

My current best guess is that I'll be ready for an early beta sometime in mid to late May, with a release in June or July. The beta will be an open beta, so anyone will be able to sample the bits.

As I've gotten further along the 2.1 road, and in response to some support issues, I've begun to think I need to change the name of QVCS-Enterprise. The new name (which may take effect with the 2.1 release) would be QVCS-MP (for multi-platform). Within that QVCS-MP umbrella name, there would be 3 separate products: QVCS-MP, QVCS-MP-Pro, and QVCS-MP-Enterprise. Vanilla QVCS-MP would have the same feature set as today's QVCS-Enterprise, except it would not support IDE integration; QVCS-MP-Pro, would add IDE integration support; QVCS-MP-Enterprise would have the QVCS-MP-Pro feature set and would add support for views. Existing QVCS-Enterprise users would get the QVCS-MP-Pro feature set, and would have to purchase some kind of upgrade to get the 'view' functionality. This is all just speculation at this point.

Keeping busy -- or... announcing a delay in QVCSE 2.1

The 2.1 release of QVCS-Enterprise will not happen until sometime in the 2nd quarter -- likely sometime in June, though it's too soon to predict an actual date.

I had earlier thought 2.1 would be out by now... but events conspired to delay its release.

The first element of the delay conspiracy: 2.1 will have more in it than I had originally planned. Initially, 2.1 was going to focus on the rename, file move, directory rename, directory move problem. However, as I got deeper into the problem, it became apparent that to do rename right, I had to add support for what I've come to call 'views'. The basic problem is how to preserve project history in the case of rename, especially when you go to create a patch build for a file that had a different name and/or location in the past. To do it right, I'm adding support for a 'view' so that you can see the project as it was at a time of interest.... and provided you've done you're labeling correctly, you'll be able to use views to make a patch build, and things will look just like they did at the time the original label was applied.... at least that's the plan. Adding view support is a lot of work -- though the ultimate client behavior will be very similar to what it is today.

The 2nd element of the delay conspiracy: I've taken on a short term consulting gig that should finish up some time in April. The consulting work necessarily distracts from development work on QVCS. I do the consulting several reasons. It helps keep me fresh technically -- I'm the sole developer on QVCS, and it helps to pick my head up from that familiar environment and get exposed to different technologies. For example, for this current engagement, I've learned how to use EJB3 entity beans, backed by the Hibernate relational persistence layer.... cool stuff.... In an earlier consulting engagement, I worked with the JBoss app server, using message beans, and JMS, etc. Doing the consulting also means I get to work with other developers, instead of working alone. This teamwork helps prime me with ideas for product improvements -- On my current engagement, we're using QVCS-Enterprise as the version control tool for our source code. That's cool, but it also helps me understand other areas of the product that need my attention... So while taking on consulting assignments involves tradeoffs, I think, on balance, it's worthwhile to do when the assignment is a good fit.

A 3rd element that will delay the 2.1 release: I'll be having an extended beta period. The 2.1 release (maybe I should call it 3.0 instead?) has a lot of changes already. It will take some time to shake it and get all the rattles out.

Technorati tags: QVCS-Enterprise

QVCS-Enterprise 2.0.20 available

I posted the 2.0.20 release over the weekend. It fixes a problem I introduced in the 2.0.19 build -- so if you are using 2.0.19 and you are using IDE integration, you will need to update to the 2.0.20 release.

The path to the 2.0.20 build is one of those embarassing moments in product development -- the 2.0.19 build was a broken build, and reaffirms a lesson in building releases that I almost always follow: always build a release in a clean directory. The 2.0.19 build was broken, not because of any coding error, but because some 2.1 code was included in the 2.0.19 build by mistake. Had I followed my own advice (always build a release in a clean directory), the problem with 2.0.19 would not have occurred.

The more basic problem I have with building releases is that the IDE portion of the build is not automated, whereas the Java portion of the build process is automated. I'll be changing that so that the entire build is automated. Oops.

QVCS-Enterprise 2.0.18, and new box shots

QVCS-Enterprise 2.0.18 is available. You can find more details here. It's been out for a while, but I've only now gotten around to annoucing here on the blog... sorry for the delay, but I've been preoccupied with work on QVCS-Enterprise 2.1, and a short-term consulting gig that I've taken on.

Along the way, to the 2.1 release, I want to dress up the web site a bit, and to that end, a first step is to create some cooler graphics that I can use to represent the 3 QVCS products. I've always liked web sites that show their software products in 'box shots', even though the product is sold electronically... so I began to play around with a tool that would help generate nicely shaded box-shot pictures for the QVCS product line.

In a web search, I found an affordable, and simple to use product called (appropriately enough) Box Shot 3D. The only problem with using this product is that you have to have some artistic talent to create the images that it uses for the front and side of the box.... so I asked my daughter to put together something, and was major league pleased with the results:

How cool is that?

Hopefully, customers will understand that they'll never actually receive a box containing software...

These new box shots will be part of the new look to the web site -- and though it will be a while before the web site update actually happens, I couldn't resist showing these off.

QVCS-Enterprise 2.0.17 available

I just posted QVCS-Enterprise 2.0.17. You can find some details here. 

This is a free update for users who have purchased their license within the past year.

2.0.17 began as a bug fix release, then morphed into something slightly more... I was working with several users to knock out some bugs, and that back and forth gave me enough time to merge in some of the changes that I'd already made for the 2.1.x release.

There remains one bug that I haven't closed -- it's been one that I cannot reproduce here -- so there might be a 2.0.18 release in short order if we can finally zero in on that problem (it's only shown up on one user's machine when they do an auto-add -- another user at that same site can auto-add the same directory tree with no problem, and I can auto-add a similar directory tree here with no problem).

The other big news surrounding this release is that I've worked with it enough on Mac OS X to feel confident in supporting it on that platform. I haven't finished dressing things up for the Mac, but it works well on that platform. Because Mac OS X preloads the JVM at boot time, application startup is fast -- barely distinguishable from startup speeds for native Mac applications.

I remember several years ago attending a JavaOne conference where Steve Jobs promised to make the Mac the best Java development platform. I'm sure you could spec out a Windows box that would come close, but the out-of-the-box Java experience on Mac OS X is pretty impressive.

Technorati tags:
QVCS-Enterprise, Source Control, Java Source Control, Mac OS X

New Authorization model for upcoming 2.1 release

In the January 2007 newsletter, I mention the changes in the QVCS-Enterprise authorization model coming in the 2.1 release (release date tentatively scheduled for March 16). I thought I'd supply a few more details here.

The basic idea is that each server action has an associated privilege. If any of the roles that a user has been assigned has the privilege to perform the given action, then the server will permit the user to perform the action. If none of a user's roles has privilege to perform the action, then the server will not allow the user to perform that action.

Already existing roles (READER, WRITER, and PROJECT_ADMIN) are carried forward to the 2.1 release so that existing users can migrate to 2.1 without making any changes; a user with the READER role will see the same restrictions as with the 2.0 releases.

The table below lists different privileges/actions -- i.e. these are the actions that can be enabled/disabled for each separate role (this list is not yet complete, as it is missing the new actions for directory meta-operations like directory rename, or directory move):

There will likely be added privileges for move directory, rename directory, and delete directory.

The cool thing about this approach is that the ADMIN user can now define new roles and associate appropriate privileges with those new roles. For example, it might be useful to define a TESTER role, and assign that role 'Get file', 'Get directory', 'Label' privileges. Another useful role might be JUNIOR DEVELOPER that had the 'Get file', 'Get directory', 'Lock', 'Unlock', 'Check out', and 'Check in' privileges. With the 2.1 release, the ADMIN user will be able to define and maintain these role definitions.

Beefing up the authorization model had been in the back of my mind since the early days of Enterprise. The pleasant surprise was that I was able to do it without breaking the existing authorization model.

Rename reprise

Since back from Florida, I've focused on putting the rename feature into QVCS-Enterprise. Along the way, I've discovered that what I had thought was a simple problem is more complex. As is often the case with software design, the devil is in the details, or put another way, it's always the boundary use cases that kill you.

In this particular circumstance, the boundary use case that I've been struggling with goes something like this:

1. You have a file that has a label that points to some existing revision within that file.
2. You now rename (or move) that file.
3. You now need to create a patch build based on the label described in step 1.

The usability problem is that after step 2, the file now has a different name, or lives in a different directory.... yet to create your patch build, you want to be able to see the world as it existed before the rename occured in step 2, i.e. you want to see the file as it existed before the rename (or move).

Other version control tools that I'm familiar with get around this problem by using a 'view', or 'sandbox', or some similar method to virtualize the user's way of looking at the files of a project.... and I'm thinking that a similar approach may be the only way to avoid user confusion.

The challenge is to make things dirt simple to use and to understand.

Directory rename in QVCS-Enterprise

After completing the code for adding file rename support to QVCS-Enterprise, I began to scope the work for supporting directory level rename, and concluded that I can't really do file rename 'right' unless I also add support for directory rename.... so directory rename will also be in the next (2.1.x) release.

Support for directory rename means beginning to treat directories as version controlled entities of a sort. There will be a server store that captures directory rename information, and a similar server store that captures file rename information.

The design/coding effort for directory rename has turned out to be easier than I feared. I'll probably be ready for a beta for the 2.1.x release in January or February of next year.

To help with the design for this renaming effort, I've been using a pretty decent open source UML tool: ArgoUML. It's got support for the main UML diagrams that I find useful: use case diagrams, class diagrams, and sequence diagrams. (It has support for other UML diagrams as well... I just don't use them). Usually, I don't bother with articulating a design -- I can design pretty well directly in Java -- but the rename problem is more complex than most of the coding problems I face, so I took the time to sketch things out in UML to help clarify my thinking. The result is a design that I'm happy with, and it turns out it will have a smaller code and performance footprint than I had thought it might.

Technorati tags: QVCS-Enterprise, Version Control Java, ArgoUML

How QVCS-Enterprise will rename a file

I've finished the first pass of coding to add the ability to rename files in QVCS-Enterprise -- this feature will appear in the 2.1.x release. The goal is for the rename operation to behave in a way that is least surprising to the user, and for revision history to be preserved.

To that end, I've come up with the following use cases that describe the way things work:

Case 1: User renames a file. Result: The file is renamed, and its revision history is preserved.

Case 2: User does a file level get-by-label request. Result: The file is retrieved using the current file name. If the file had a different name when the label was applied, the user is warned that the current filename differs from the filename at the time the label was applied, but the current filename is used anyway.

Case 3: User does a file level get-by-date request. Result: The same as Case 2, except use the date instead of the label to determine whether the file had a different name at the given date.

Case 4: User does a directory level get-by-label request. Result: The file is retrieved using the name that was in use at the time the label was applied. (Contrast this with the behavior for Case 2). The user is warned that the filename is different.

Case 5: User does a directory level get-by-date request. Result: The same as Case 4, except use the date instead of the label to determine whether the file had a different name at the given date.

The basic idea here is that when you do file level operations, you expect the filename to remain the same... when you perform directory level operations, I suppose you might expect the same behavior, but as it's coded today, you'll get the filename that was in use at the time the label was applied, or the filename that was in use at the given date/time. I have thought it might be useful to allow the user to choose whether to use the current filename, or use the filename that was in use in the past.

One of the reasons I wanted to write this down was to see if it really makes sense, and also solicit reaction to see if other users view the behavior as non-surprising.

Along the way to getting rename to work as described above, I decided to bite the bullet and create a time/date control to allow the user to enter the date/time (when doing a get-by-date (a new feature)). I searched the web for date/time controls, found a few, but none that really matched my requirements.... so I created my own. The control allows you to enter both the date and the time... (the ones I had found on the web did not allow you to easily define the time).

The underlying implementation is just a JTable, with a data model behind it based on a Calendar object. The control is locale aware, though I haven't tested that part. The days of the week letters and month names should adjust automagically for non-US locales,

It took several days of playing around to arrive at a result I was happy with. The ultimate goal will be to integrate its use throughout the rest of the client application so that entering a date/time becomes a simple point/click type of operation.

Technorati tags: QVCS-Enterprise, Version Control Java, JCalendar

My, er, I mean Quma's new iMac

It's beautiful.... my (Quma's) new iMac/24.

It's fast and the Mac Java implementation is especially fast.

And QVCS-Enterprise 2.0.12 mostly works.

There are a few glitches: the file open dialogs don't include the button that allows you to create a new directory; you can't use the open file dialog boxes to navigate past a Mac .app directory in order to locate the actual executable that the client application can launch when you double click on a file (to name just a couple of the problems I've identified).... but the important functions work as expected: get, checkout, lock, unlock, checkin, label, etc.... cool.

We ordered the Mac (my wife placed the order using a discount that Apple offers to employees of her firm) on November 24 from apple.com. It shipped on the 27th from Shanghai (free shipping), and arrived here (on the east coast) on November 30 before 10:30 am... via FedEx... Half way around the world in less than 1 week.

Unpacking (just 1 box!) and setup (only keyboard and mouse and power cables) were a snap. I'm still learning my way around MacOS.... It's not hugely different... you just have to become familiar with the different place for the window minimize and maximize buttons, and the use of the application menu at the top of the screen, instead of at the top of the application's frame window... and I still have to get used to using the Apple key instead of the control key, and haven't yet figured out all the keyboard shortcuts for effective typing in an editor window.

The dashboard is cool, but I haven't decided yet whether it has real value, or if it's just a toy. The mouse took some getting used to... you have to change the default mouse preferences in order for it to behave like a standard Windows 3-button mouse. Without that change, the context menus (click the right mouse button) would not display.

NetBeans works great, and the ant build script for QVCS-Enterprise ported over with only one minor change (the Mac's flavor of Java does not have an rt.jar file, so I had to make a 1 line adjustment to the ProGuard script that I use to obfuscate the code).

OpenOffice works also, though it's a little more klunky -- it runs under X11, which means you have to manually install the X11 windowing system in order to get it to work.... a nuisance.

The next QVCS-Enterprise release will 'officially' support the iMac (Mac OS X 10.4.8 is what the new machine is running), but I'm willing to work with Mac users now to get things to work in more useful way.

QVCS-Enterprise multi-platform support now has more substance: XP, W2K, Windows 2003 server, Linux, Solaris 10, and now Mac OS X.... Made possible by Java --- write once, test everywhere. Did I say cool? Yeah!

Technorati tags: iMac, QVCS-Enterprise, Java, NetBeans

QVCS-Enterprise 2.0.12 build available; Partial roadmap for 2.1

As promised yesterday, I posted the QVCS-Enterprise 2.0.12 build this morning.

It cleans up a few problems from the earlier 2.0.x builds -- more details are available here. 

Now... on to QVCS-Enterprise 2.1. The product roadmap for 2.1 includes support for file renaming, and possibly support for file moves, directory renames, and directory moves. These latter features are especially tricky... so I'm not sure if they'll 'fit' into 2.1 or if they'll arrive in a later release. They are all important features to have as more and more developers use tools that make code refactoring easy to do.

Using Parallel's VM's for other platform support

Over the past week, I've been getting the Enterprise 2.0.12 build ready -- it will be released tomorrow. Along the way, I thought it would be nice to verify that it works on the lastest Fedora Linux, and also to see if I could get it to work on Sun Solaris 10.

The short answer is that QVCS-Enterprise (2.0.12) now works on both these platforms... as well as Windows XP, and W2K.

To add support for these additional environments, I've been using an evaluation copy of Parallels Workstation . It provides support for a number of different 'guest' operating systems, including numerous flavors of Linux, as well as Solaris 10. I made a few minor cleanup changes in the Enterprise Java code, and voila, things are working well on both platforms.

The most difficult thing I ran into was the Solaris install. I had to try it several times, tweeking things this way and that, until it finally took. Parallels provides some support forums  that helped to figure out some things to try. The Fedora install, in contrast, was pretty simple, though in fairness, I've done many Linux installs in the past.

Both operating systems are simple enough to use, once you get them installed. Solaris comes preinstalled with Java 5, so I didn't have to do anything there to get Java support. For Fedora, I still had to download and install the Sun JVM.... though I suppose that will soon change, since Sun has now open-sourced Java under the GPL.

Performance within the Parallels VM is pretty good -- though I will probably spring from some more memory so that things don't swap as much as they do now (I have only 1 Gig on the workstation I'm using for testing).

It's too bad that Apple doesn't provide a version of their OS. I've seen rumors that users have succeeded in getting it to run in a VM... but that's not sanctioned by Apple. The new iMac's look pretty cool... so maybe I'll just get me one for Christmas... then I'll be able to include the Mac as an officially supported platform for QVCS-Enterprise.

Visual Studio 2005 and ~sak temp files

Visual Studio 2003 and VS 2005 sometimes use ~sak.... named temp files to probe the capabilities of a version control provider. The relavant Microsoft MSDN article is here.

Neither QVCS-Pro nor QVCS-Enterprise support the use of a MSSCCPRJ.SCC file described in the article, so in order to get Visual Studio to forego the use of these ~sak... temp files, it's necessary to add a registry setting that tells Visual Studio to skip the creation of these feature probing temp files.

QVCS-Pro 3.10.14 does this already for VS 2003, but it does not do it for VS 2005. The QVCS-Enterprise client installer does not set the registry key at all.

If you want to disable the creation of these ~sak files, for VS 2005, you can manually set the following registry key:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\SourceControl] "DoNotCreateTemporaryFilesInSourceControl"=dword:00000001

For VS 2003, the corresponding registry key is:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl] "DoNotCreateTemporaryFilesInSourceControl"=dword:00000001

Visual Compare for .doc files and spreadsheets

QVCS can version control anything that's stored in a file -- including binary files. Performing a visual compare on binary files, however, is usually worthless unless you use a visual compare tool that is 'aware' of the file format for the given binary file type. For some of the popular binary file formats, these kinds of visual compare tools exist. For example, you can use a tool from Zizasoft to perform visual compares of Microsoft Word documents. Alternately, you could use a tool from Formula Software to compare different revisions of an Excel spreadsheet (See our resources page for some other alternatives).

Suppose you want to be able to use these tools, and still use a vanilla visual compare utility for the rest of your files? Can that be done? Yes... but you have to use a batch file so that different file extensions will launch different file compare utilities. For QVCS and QVCS-Pro, you need to create a batch file that looks something like this:


IF %~x1==.DOC goto docFiles
IF %~x1==.doc goto docFiles

IF %~x1==.XLS goto xlsFiles
IF %~x1==.xls goto xlsFiles

:otherFiles
"C:\qvcsbin\ExamDiff.exe" "%1" "%2"
goto end

:docFiles
cd "C:\Program Files\Zizasoft\zsComparePro"
zsComparePro.exe '/leftFile:%1' '/rightFile:%2' /fileOptions:"By Character" /noSplash
goto end

:xlsFiles
cd "C:\Program Files\Excel Compare"
xlsc.exe "%1" "%2" /allSheets
goto end

:end


In QWin3, you would then select the Admin/Preferences... menu, and on the Utilities tab, enter the path to the batch file so that it looks something like:


C:\qvcsbinTest\myCompare.bat "%s" "%s"


For QVCS-Enterprise, you can do something similar. You can use the same batch file described above. To get the QVCS-Enterprise client to use this instead of the built-in visual file compare, you need to start the client, select the Admin/User Preferences... menu option, and on the Utilities tab, enable the 'Use External Visual Compare Tool'. In the associated edit box, you need to enter a command line that looks like:


C:\qvcsbin\myCompare.bat file1Name file2Name


QVCS-Enterprise 2.0.11 released

Yesterday, I posted QVCS-Enterprise 2.0.11.

This is a bug-fix release that addresses several problems discovered in 2.0.10. Existing 2.0.10 users should just replace their server_out.jar file (after shutting down their server) with the one contained in the 2.0.11 distribution. Client updates will occur 'automatically' as a result of the client attempting to login to the new version of the server. If you use IDE integration, exit your IDE, then run the client application (gui.bat) to update your client. Once your client is running 2.0.11, then the IDE integration .dll will be updated at the same time as your client application (gui_out.jar). The admin application also updates automatically.

Users of 1.x releases should follow the update instructions described in the readme.txt that's part of the distribution.

The list of fixes in 2.0.11 can be found here. 

IDE Integration tip

I had a tech-support issue come up the other day related to getting IDE integration to work. In sorting through the issue, it turns out that neither QVCS-Pro nor QVCS-Enterprise is very friendly to the non-admin user.... i.e. they both need admin rights to make the necessary registry changes that are required by Microsoft's SCC IDE integration.

Since I'm an admin user on all my machines, it's not a problem I've ever run into. I guess it also goes without saying that neither am I a Windows admin guru. We came up with a successful workaround, and I'll be creating a FAQ on the solution as soon as I can put the pieces together into a coherent presentation.

In the meanwhile, if you are a non-admin user who has given up on getting IDE integration to work, the basic problem can be solved by changing the rights on two hives in the registry.

What you have to do is described nicely by this article (for a product completely unrelated to QVCS or QVCS-Enterprise). Instead of the BSI hive (described in the linked article), you would need to modify the SourceCodeControlProvider hive and the QumaSoftware hive in the same registry tree as described in the article.

New feature poll

I created a new feature poll for QVCS-Enterprise on the forum site.  The idea is to capture some feedback and suggestions so I can prioritize what goes in to the next release of the product. Please stop by and add your two cents.

UPDATE: Add link to forum.

QVCS-Enterprise 2.0 Now Available

Whoo hoo!

QVCS-Enterprise 2.0 is now out. It was a lot of work... as you can get some sense of here. ...or for the full report of changes since 1.2.13, take a look at this report (generated with QVCS-Enterprise, of course).

My thanks to beta testers who helped iron out the bugs.... this release feels pretty good and your assistance helped get to that point. I've been using it for a long time now, and it's been solid.

This release has a lot of under-the-hood changes that should improve the user experience. For example, the client (both the client application and the IDE client) now generates a 'heartbeat' message every 10 minutes. This is done silently, but has the effect of sending application traffic over the TCP connection that exists between the client and server. This should make it much less likely that the network infrastructure will time-out your TCP session... so you should be able to login once, and remain logged in for the entire day without having to do anything within the client to keep the connection alive.

This release also adds color coded icons in the file list display. This popular QVCS/QVCS-Pro feature is turned off by default -- but you can turn it on via the Admin/User Preferences... dialog. When enabled, files that have a status of 'Current' have a green dot, those that are 'Missing', or 'Stale' will have a yellow dot. This screen shot (at the bottom of the page) gives you an idea of what I'm describing.

And on and on. Try it. You'll like it.

QVCS-Enterprise pricing

QVCS-Enterprise prices will be going up with the 2.0 release on August 31. The new price will be $49 per concurrent client. The old price was $99/4 users -- or around $25/user. The other change in pricing is that beginning with 2.0, you'll be able to buy single user licenses -- so prices start at $49 instead of $99. A standard discount schedule will apply for volume purchases.

(A concurrent client is any user who must login to the server. This means that a single user who uses both IDE integration and the client application at the same time consumes 2 concurrent clients -- 1 for the IDE integration, and 1 for the client application, since each require a separate login to the server).

The justification for the price increase is increased and improved functionality (e.g. IDE integration). With IDE integration, QVCS-Enterprise offers close to the same functionality as QVCS-Pro, while providing better performance, much better support for remote users, and multi-platform support. The original $25/user pricing was meant to be an introductory price for a 1.x product. With 2.0, that introductory period is over -- With 2.0, the product is more mature, and still an incredible value at $49/concurrent client.

Of course, if you like the old pricing, you can still buy QVCS-Enterprise at those old prices through August 30. You'll get to upgrade to 2.0 'for free', since 2.0 will appear within 1 year of your original purchase.

QVCS-Enterprise 2.0.9 beta available

I just posted the 2.0.9 beta. You can get the bits from the usual location. 

This beta is finally feature complete. As noted in the previous entry, the new feature adds support for user defined reference file locations. (In earlier releases, the reference file location was hard-coded into the application).

I still have to add some more documentation, and verify that the existing docs are accurate. I also have to verify that things work as expected on Linux, and finally, I want to spend some time poking around with the NetBeans profiler to verify that I don't have any memory leaks, and also to try to look for places to goose performance a bit.

On that latter note, for testing, I've got a test project with some 35,000 files in it. I routinely go through testing cycles where I create the entire project tree, and then view and sort the files of the entire project, looking for performance issues. Admittedly, things can be slow with a project that large, and there remain some anomolies (read bugs?) with screen refresh when bouncing back and forth between enabling and disabling directory recursion. I figure if I can get things to behave in a useful way with a project that large, then things should work real well with smaller projects. Having a project that large also gives me a real good sample set so the profiler can highlight where the app is spending its time.

I don't know whether I'll have another beta before the 'official' release on August 31 -- I guess it will depend on whether we find any issues with 2.0.9.

Feature creep

Since I like writing code more than I like writing documentation (who would have guessed!), I added yet-another-feature to 2.0: the ability to choose an alternate location for reference files on the server.

In QVCS-Enterprise, if you enable the creation of reference files, by default, those reference files will be created in the qvcsProjectsReferenceCopies directory tree (beneath the server install directory). This new feature allows you to specify some alternate location for the reference files.

The feature is simple minded -- since the admin tool can run anywhere, it cannot verify that the string you enter for the directory name is valid (think running the admin tool from a Windows box, talking to a Linux server, or vice versa) -- that validation occurs on the server... If you enter a useful string, i.e. one that is valid, then things work like a charm. If you enter an invalid string, the server will reject it, and the requested change to the project's properties will be discarded.

Reference files (a.k.a shadow files), are just copies of the most recent default revision for the associated workfile. They're handy to have if you want to share your work product with folks who are not users of QVCS-Enterprise.

QVCS-Enterprise 2.0.8 beta available

And the hits just keep on coming...

I posted the 2.0.8 beta yesterday. It's the first 'feature complete' beta. I was able to get file group support in (client side only), and added some confirmation dialogs for when you delete a file, or when you delete a workfile.

Along the way, we discovered that the IDE integration in 2.0.8 doesn't work completely with VB 6.0 -- that's now fixed, and will appear in the 2.0.9 beta (scheduled for August 22).

File groups work pretty much the same way as in QVCS/QVCS-Pro. By default they are disabled. You define file groups via the 'Define File Groups' dialog, and enable/disable them via that same dialog. If they are enabled, and a file that you select is a member of a file group, then all other files that are members of that same file group are automatically selected. The definition of a file group is also the same as in QVCS/QVCS-Pro: files that share the same file name, but have different file extensions are candidates for being members of a file group.

File Groups are an important feature for some toolsets. In VB, for example, if you checkout a .frm file, you should also always check out the associated .frx file. Delphi has similar file pairs/groups.

In any case, the feature is now there to play with. It's actually pretty fast -- to me it seems faster than QVCS/QVCS-Pro.

In tracking down the problem with VB IDE integration -- it turns out that VB needs/requires file group support in order to behave correctly -- or at least by adding some elementary file grouping behavior, it's a lot happier than it was without it. Read on for some gory details.

The QVCS-Enterprise IDE integration is as simple as I can make it... i.e. it has only as many features as are needed to get things to work with the popular IDE's. The idea is to allow you to do simple version control behaviors from within the IDE, and to require you to use the client application if you want to do more complicated version control actions. This strategy works well with most IDE's, but VB needs the version control plugin to provide more behavior than some other IDEs (VS 2005 for example). The behavior that was missing was a file grouping behavior.... adding that in made things work correctly.

The file grouping behavior that the QVCS-Enterprise IDE integration supplies is not the same as the file group behavior provided by the client application. In the client application, you are allowed to define the set of file extensions that participate within a given file group. In the IDE integration implementation, the file grouping is supplied to all files that share the same base file name -- i.e. any file that has the same base file name but a different file extension is a member of a file group. This makes it so that when VB asks the IDE integration to operate on a .frm file, the IDE integration will 'automatically' add the .frx file to the set of files that should be included within the requested operation.

QVCS-Enterprise 2.0.7 beta available

Yesterday I posted the QVCS-Enterprise 2.0.7 beta. I hope to get to where I'm feature complete on the 2.0 release by the end of this week -- though I'm not sure that I'll make it.

The coolest thing to go into the 2.0.7 build is support for auto-updates of clients. This means that for releases after 2.0.7, you'll only need to update the server_out.jar file on the server. Clients that connect to that server will get updated automatically to the client release that matches the server. This will make it much easier to manage updates.

Another nice-to-have in 2.0.7 is support for 2 separate administrator roles. The ADMIN user retains the same functions as in earlier releases. Now, in addition to the ADMIN user, any user with a PROJECT_ADMIN role for a given project can login using the admin tool, and perform project level administration for those projects. So, for example, a PROJECT_ADMIN user can define user roles for a project. This makes it so the ADMIN user can delegate a lot of the project administration duties to other PROJECT_ADMIN users.

Another more visible change in 2.0.7 is the use of colored file icons (like those available in QVCS and QVCS-Pro). The plan is to add a user preference so that you can choose whether to use the colored icons or not -- for now, their use is hard-coded into the client.

The big things remaining on the TO-DO list that will likely make it into the release:

• Some final cleanup of some of the IDE functionality.
• Fleshing out user preferences into a tabbed dialog.

Updates galore

This past week, I've posted updates for both QVCS-Enterprise (1.2.13) and QVCS/QVCS-Pro (3.10.12).

Both of these updates are bug fix releases.

In the case of QVCS-Enterprise, the new build fixes a problem that shows up when you have users who have different ways of capitalizing the name of the same file. For example, if user A has a file named foobar.java and user B has a file named FooBar.java, QVCS-Enterprise will normally see these as different files. If, however, you have enabled the 'ignore case' project level setting, QVCS-Enterprise is supposed to treat them as if they were the same file. The 1.2.13 release makes it so it finally does treat them as the same file.

So why does QVCS-Enterprise even allow foobar.java and FooBar.java to be considered as separate files. The simple answer is that in *NIX environments, the file system treats foobar.java to be different than FooBar.java. Since QVCS-Enterprise is cross-platform, it should support this scenario. Admittedly, this should be the rare case, but in software, it's often the boundary cases that drive both requirements and design choices.

In the upcoming 2.0 QVCS-Enterprise release, new projects will have the 'ignore case' setting enabled by default. Note that with the current 1.2.13 release, if you change the 'ignore case' project setting, you'll need to restart the server in order for the change to take effect.

The 3.10.12 release of QVCS/QVCS-Pro is strictly a bug fix release -- it fixes a problem with the 'login as' feature.

You can get the bits for the latest stuff from here. 

QVCS-Enterprise 2.0.4 beta now available

Yesterday, I posted the 2.0.4 beta. You can download it from here. 

This beta begins to flesh out the directory level operations from the client application. With 2.0.4, you can do a directory level 'get' operation, directory level label, and directory level unlabel. This stuff is not feature complete yet, but it is functional. There are fewer round-trips to the server, so things are a bit faster than selecting an entire batch of files and performing the operation on that set of selected files (as is required in the current 1.2.12 release).

I plan to have 2.0 feature complete by mid-August, and available for general release at the end of August.

QVCS-Enterprise 2.0.3 beta now available

It's still a work-in-progress, but I wanted to post this build to fix some of the more troublesome bugs present in the 2.0.2 beta.

This beta also begins to rough in some project level operations (e.g. the get operation). The current implementation is not yet complete, so use it at your own risk. (It does not do a good job of testing for overwrites, for example).

To get this to work correctly, you need to make sure to update your clients with both the gui_out.jar, and make sure to add the swing-layout-1.0.jar to the lib directory on the client. You'll also need to download and re-run the client installer program (to update the IDE .dll).

When you run your client for the first time, you'll have to re-enter your workfile locations for each project that you use -- I had to refactor some of the code in this area to get things to work correctly for some scenarios with IDE integration.

The IDE integration is now close to feature complete. It now includes option support so you get 'get by label', or checkout 'by label'. You can also apply a label at checkin time. Whether you can actually do this from within your IDE will depend on the IDE -- it does work in Visual Studio 2003 and VS 2005.

QVCS-Enterprise 1.2.12 release available

Yesterday, I posted the 1.2.12 release. It's a bug fix release that addresses the bug I described in this blog entry.

You can download the bits from the usual location. 

QVCS-Enterprise 2.0.2 beta now available

I just posted the bits for the 2.0.2 beta.

It's not yet feature complete, but it's got the big feature for the 2.0 series of releases: support for IDE integration.

The documentation has been updated some, though I still have some work to do there. The cool change with the way the docs are provided is that the docs are now embedded within the server .jar file. The downside of this change is that users can't easily edit the web site that the server provides. The advantage of this approach is the guarantee that the link to the associated client .zip file is accurate.

There are several things that remain to be completed for the IDE integration. For example: addition of support for command options for the various actions that you can perform within the IDE. Suppose you want to apply a label to a file when you check it in -- that functionality isn't yet completely there.

If using IDE integration, the biggest thing to be wary of (that comes to mind): the transport is not secure. This means that if you want any kind of security, you'll need to connect via a VPN, or similar mechanism. You also need to use the client application to define the external visual compare utility that will be used within the IDE for visual compares.

Aside from the additions to IDE functionality, the rest of the work going into the production release of 2.0 will focus on usability improvements. I've got a pretty long list of TO-DO's in this area (not all of them will get done before the release) -- if you've got a suggestion that you'd like to see implemented in 2.0, now's a good time to let me know.

Java puzzler

There is a bug in QVCS-Enterprise 1.2.11 (and earlier releases) that only just came to light. You can get a little background from this forum thread.

The bug only shows up if you run your QVCS-Enterprise server on a Linux platform. The puzzler was to figure out why things were behaving differently on Linux than on Windows. I set up my Linux box as a server for remote debugging and spent some time tracking down the problem. As it turns out, the problem was caused by slightly different behavior on Linux.

The offending (a.k.a buggy) line of code looks like:

int descriptionLength = 1 + description.length());

where description is just an instance of a String object.

The bug-free (a.k.a fixed) line of code looks like:

int descriptionLength = 1 + description.getBytes().length;

This implies that on Linux at least description.length() != description.getBytes().length.

This is a surprising result, at least to me. I had thought that the length of a String would be the same as the length of a String's byte[]. As the above code shows, and the Linux JVM confirms, this is not universally true. It's probably documented somewhere, and it probably has something to do with different internal String representations on the respective platforms. In any case, it's the kind of subtle bug that demonstrates the Java mantra of "write once, test everywhere".

This is okay. In my experience in using Java across platforms, almost always, deploying on a different platform helps expose bugs in your own code instead of exposing bugs in the JVM.

I'll be publishing a fix for this bug later this week. If you need the fix immediately, a patch is available.

Keeping busy

Busy, busy, busy.

How many balls can you keep in the air at a time?

I'm writing this from my hotel room. I'm on a short term consulting gig for my former employer. I didn't burn any bridges there when I left to work on Quma full-time last year, and thought I could help them out. The consulting is interesting enough, but it's keeping me busy during the day -- so QVCS work slides back to the evenings where it lived for many, many years.

As a consequence of the consulting work, it looks like the release date for QVCS-Enterprise 2.0 will push off until late summer or early fall. As I've noted earlier, the big new feature in Enterprise 2.0 will be support for Microsoft's SCC IDE integration. I've made some good progress with it over the past several months, and have it far enough along that I can self-host its development: check-outs, check-ins, revision history, visual compare, and revision compare all work like they do in QVCS-Pro. I still have a few more functions to implement, and have to add PowerBuilder support (which should be pretty easy). I'm shooting to have an early beta ready in several weeks. This will be a beta without installer support -- you'll have to manually muck around in the registry to get things set up so an IDE will 'know' about QVCS-Enterprise, but ... the functionality is there, and I need to get some other folks working with it to identify areas that still need some polish, and to help find any bugs.

On the QVCS/QVCS-Pro front, I'll publish a bug-fix release at the end of this month. There are a few relatively minor bugs addressed in this next build. Chief among them is improved support for very large files. I had a user a while back who was having trouble getting QVCS to work with very large files (>50 Megabytes)... things would work fine if everything was done on one machine, but as soon as he tried to get things to work with a file server over the LAN, things would fall apart. More recently, another user has run into this same behavior, and this time, I've been able to duplicate the problem.... and fix it. The code change breaks up the writes into smaller chunks instead of attempting to write the entire gazillion bytes in a single write. I would have thought that the underlying runtime libraries would have handling this kind of chunking, but apparently not.

Early bird special; MFC CSocket advice

I just uploaded the likely bits for the upcoming 3.10.7 release. The official release date is this Friday; but you can get the bits early here. I say likely, because I don't expect to make any additional changes to the code between now and Friday -- unless there are some late bug reports.

Things have been quiet on the blog because I've been preoccupied -- coding away on both the 3.10.7 release and the 2.0.x Enterprise release. As noted above, the bits for 3.10.7 are now stable. 2.0.x Enterprise is a completely different story.

The big feature for 2.0.x Enterprise is be the addition of support for Microsoft SCC IDE integration (like QVCS-Pro). To implement this, I've been writing the IDE client piece in C++, and making the corresponding transport changes in Java for the server code. Along the way, I implemented socket code on the client to communicate with the server, just like the existing Java client. One of the twists that requires server changes is that I can't use Java Serialization on the C++ side for object serialization, since I don't have a JVM on the client. This means writing a serialization layer on both server and client to push the bits back and forth. The result is a better use of bandwidth, at the expense of writing and maintaining the serialization code.

Since QVCS and QVCS-Pro are MFC based C++ applications, I figured I'd write the client SCC .dll as an MFC based .dll Since I had to do socket communications between the MFC C++ client and the Java server, I figured I'd use an MFC supplied socket class. As it turns out, that was a mistake that cost me several days of frustration: I tried to use the MFC CSocket class, since it seemed to be a closer fit to what I needed. For whatever reason -- it was not a good use of my time to try to debug what was going on -- the CSocket class really did not fit the threading model that I needed to support. There must be some scenarios where CSocket can work, but it was not reliable at all in the way that I was trying to use it. The Microsoft docs were not helpful in pointing out the limitations of the CSocket class -- for that I had to rely on dribs and drabs of complaints that I found via Google search.

In the end, I punted, and wrote my own socket class that wraps the Windows socket API's, based on some sample code I found on the Internet. It works well, and is actually very simple. My guess is that almost everyone else who has to write socket code in an MFC environment goes through a similar two days of agony, and then does the same thing that I did. The result is more reliable with well defined behavior than the MFC supplied alternatives.

The bottom line advice -- if you are thinking of using the MFC CSocket class for anything useful, think again.

Updates for New Years

I just uploaded updates for both QVCS/QVCS-Pro and QVCS-Enterprise.

For QVCS and QVCS-Pro, you can read the details here. 

For QVCS-Enterprise, you can read the details here. 

Happy New Year!

Holiday Distractions

The holidays generate many distractions. The distractions are the kind that make the holidays a happy time:

• picked my daughter up from college...
• went to visit my son and his fiance -- he's on his own, and has been now for close to 2 years.
• shopping
• "must see" movies (Pride and Prejudice)
• peppermint ice cream...

Between the distractions, I've been working on cleaning up some bugs in QVCS 3.9.23, and some bugs in Enterprise 1.2.10. Both will get refresh/bug fix releases near year end.

The 3.9.23 bugs are subtle, and not urgent (which is why they haven't been fixed already). One area of cleanup surrounds the correct treatment of obsolete files. In QVCS, an obsolete file is one that cannot be changed (it's obsolete), but is available for 'get by label' operations for those cases where you need to get an old revision for building an old release (for example). The goal of the changes is to make the handling of obsolete files more transparent than is currently the case. Along the way, I've had to cleanup some subtle problems with the file rename operation. The last of those changes went in today. Thanks to David A. for reporting a weird boundary case that turned out to be related to the rename operation.

This next QVCS/QVCS-Pro build will also add support for two new keywords suggested in this forum topic. 

The Enterprise changes are also minor: In some rare cases, the server shutdown doesn't happen in a clean way leading to corruption of the role store and/or the authentication store. The symptoms are the sudden disappearance of projects and/or the sudden disappearance of users. The bug is very difficult to reproduce, but the changes for the next build should address the issue. The next build will also include support for the same 2 new keywords mentioned above for QVCS/QVCS-Pro.

QVCS-Enterprise 1.2.10 Released

I just posted QVCS-Enterprise 1.2. The main thrust of this release is usability improvements. The changes include:

• Support for the $Project$ keyword. It expands to the name of the current project.
• The main window now has a lot better keyboard support, so you can do many common things without having to resort to the mouse.
• Improved the handling of the $Version$ and $Label$ keywords (they are synonomous). The expansion algorithm for these now matches the expansion algorithm in QVCS/QVCS-Pro.
• Added the ability to ignore case in filenames. This is a useful feature for Windows only shops.
• A number of usability improvements to the admin tool.

More details are available here.

This will be a free update for users who purchased their license within the past year. For licenses older than that, you'll have to purchase a license update.

How big is your... QVCS Project

I've put a poll up on the forum site here. Please take a look, and vote. I'd like to get a read of the typical QVCS project size.

The poll is prompted by a support thread  on the forum where the user is wondering why QWin takes so long to start. I'm not confident that we've gotten to the bottom of what's going on, but along the way, I learned that the user had close to 10,000 files in the project, and that one directory had over 4,000 files.

QVCS can handle projects that large, but startup will be slow, especially if the cache files haven't been built yet. Also, there's added work in computing the digest values for the workfiles. This all adds up to a slow startup time for a large project. Once the cache files have been built (a one time thing), and the digest values have been computed (a one time thing), then subsequent startups should be faster -- provided things haven't changed since the last startup. By that I mean, that if QWin detects that a workfile has changed since its digest was last computed, it will re-compute the digest for that workfile.

In any case, please take the poll.

QVCS product family newsletter

One of the recurring suggestions from the SIC conference: create and publish a newsletter to help keep your user community informed. This 'communicate with your users/customers' is an area where I need to improve -- so I decided to take the SIC lesson to heart, and begin the process of creating a monthly newsletter.

It will be available to anyone who wants to subscribe.... (see the Quma home page (top right of the page) for the link to add yourself to the mailing list). It's a double opt-in list, meaning that you have to send a confirming e-mail to actually get added to the list. All the standard privacy stuff applies -- I won't share your e-mail address with anyone else, etc., etc.. The plan is to publish once a month, probably around mid-month. The newsletter will be brief, and contain tips and tricks, product update information, and pointers to forum and blog topics that may be of interest to the QVCS user community.

For tools, I'm using Mail List King Professional. I've only had it for a day, but it seems pretty easy to use, and will make maintaining the newsletter mailing list pretty painless. It's got its own embedded SMTP server, so outbound traffic doesn't even hit my ISP, which is good. ISP's are pretty gun-shy about anything that looks like spam, and sending out a newsletter could look like spam to some folks.

QVCS-Enteprise 1.1.11 now available, 3.7.17 update too

I just posted the 1.1.11 release of QVCS-Enterprise. This is strictly a bug fix release -- it has only one change: it fixes a problem with server shutdown in the case where the server is running as a Windows service.

I also posted a 3.7.17 release which is a bug fix release for 3.7 users. The fixes are those that I discovered as part of the work for the 3.8 release. If the fix was easy to get into the 3.7 code base, then I bundled it into the 3.7.17 build. There's nothing fancy here, but it does provide improved behavior for the named file filter combo box, and a few other changes. Details are listed on the What's New page -- just scroll down to find the 3.7.17 release.

The 3.7.17 release is a free update to registered 3.7 users. To install it, just unzip the distribution file over top of your existing 3.7 release.

3.8 users will not want to do anything with 3.7.17, since all the changes in 3.7.17 are also present in the 3.8 code base. 3.7.17 is meant strictly as a maintenance release for 3.7 users.

QVCS-Enterprise 1.1.11 Coming Soon

Turns out there is a bug in the 1.1.10 release. It's only an issue if you are running the server as a Windows service. If that's the case, then you should use the admin tool to shutdown the server instead of stopping the service. The 1.1.11 release will fix the problem so that stopping the service will be an acceptable way to shutdown the server.

New QVCS releases now available

I posted the latest releases for QVCS/QVCS-Pro (3.8.18) and QVCS-Enterprise (1.1.10).

Both of these releases are pretty significant. Feedback is welcome.

Drag and drop for QVCS-Enterprise

One of the features I use most in QVCS-Pro is its drag and drop support. I mostly use the 'drag' support, where I'll drag a file from QWin and drop it into VS.Net or notepad, etc. It bugged me that I didn't have that kind of drag support in QVCS-Enterprise....

Well now I do. I had thought adding that kind of drag support would be a lot of work -- the documentation for Java drag-and-drop is a little daunting, and the behavior has been a bit of a moving target between Java 1.2 and Java 1.4. It turns out to be pretty easy to do, and required perhaps 50 lines of code, if that. I haven't tested it on Linux yet, but it works well enough on Windows that it's a keeper, and will appear in the upcoming 1.1.10 release next Tuesday.

The drag 'gesture' seems to be just a little different that the default behavior for Windows, but it's easy to get used to, and the feedback of the cursor where it changes to the '+'-arrow makes it easy to tell when you've successfully grabbed the file that you're going to drag. For this iteration, I'm only supporting the drag of a single file.

The drag support means Enterprise will have half of the drag-and-drop support that QVCS-Pro supports --- QVCS-Enterprise is not a drop target, whereas QVCS-Pro can be.

UPDATE: Drag support also works for Linux.

Wrapping up a double header

I've wrapped up coding on both QVCS/QVCS-Pro 3.8 and QVCS-Enterprise 1.1. Current plans are to release them both on May 31.

The QVCS-Enterprise release will be a free upgrade for existing QVCS-Enterprise users. It includes some features I've mentioned before as well as some other usability improvements that I had time to squeeze in:

• Screen sizes and splitter bar positions are now preserved.
• You can enter a comment at checkout time, and that comment will be the default comment used at checkin.
• If you have defined a viewer application for .html files, the generation of a report will automatically launch your .html viewer (presumeably a browser) for the report.

I'm now in the process of updating the web site, doing some final testing, and waiting for any final bug reports from the QVCS/QVCS-Pro beta users.

QVCS/QVCS-Pro Refactoring

There has been a 'feature' in QVCS/QVCS-Pro for a while now: if you apply a label at checkin time, then QVCS will always make a new revision for you, whether the file you are checking in is actually different from the revision that was checked out, or not. This is clearly not the correct behavior. The correct behavior for an unchanged file would be to simply apply the label to the revision that had been locked, unlock that revision, and not create a new revision. (The QVCS/QVCS-Pro workaround is to not apply the label until after the checkin, which can be a nuisance).

Well, in the upcoming 1.1 release of QVCS-Enterprise, I've added the ability to apply a label at checkin time, and in QVCS-Enterprise, it works as it should.

If QVCS-Enterprise can do it, then QVCS/QVCS-Pro should do it to! The reason I delayed implementing the same behavior in QVCS/QVCS-Pro is that.... you know how sometimes when you write code, and then add more and more features to it, it becomes.... complex? Well, that portion of QVCS/QVCS-Pro is pretty complex. I've stayed away from changing it for fear of breaking it. Fear no more. I've decided to refactor that whole section of code so that it is much more closely aligned with the Java implementation in Enterprise. The Enterprise code is actually pretty clean in this area, and the goal is to get the C++ code up to that same level of cleanliness. Along the way, there is a whole lot of refactoring going on. When complete, I'll have a body of code that is much easier to maintain, and will also (finally) do the right thing when applying labels at checkin time.

QVCS-Enterprise in the pipeline

I've begun work on the next QVCS-Enterprise release. So far, I've finished these changes:

• Added a Revision and Label info pane. This pane provides label as well as revision information for the selected file so you can see on a single pane what labels are associated with a given revision. I haven't decided whether to retain the existing 'Revision Information' pane. The new pane contains a superset of the information shown on the existing pane, but some users may prefer the more condensed display of information.
• You can now 'view' a workfile by double clicking on the file in the file list pane.
• You can now 'view' an older revision of a file by selecting the 'View Revision' menu option from the context menu that is shown when you right click on a file.
• You can now change the comment prefix on a file. The comment prefix is only used if you have keyword expansion enabled and you use the Log or LogX keyword.
• You can now change the file description after an archive has been created for a file. This description shows up in the expansion of the Log or LogX keyword.
• You can now change a revision description after you have checked in a revision. This changed revision description will show up in the Log or LogX keyword expansion when you next 'get' or 'checkout' that file.
• You can now apply a label at checkin time.
• You can now force a branch at checkin time.

I've decided not to implement the ability to assign a revision number at checkin time. This was always a source of confusion in QVCS/QVCS-Pro, and really does not add any value to the product. Labels are a much more appropriate way to create an association among a set of files.

QVCS-Enterprise 1.0.20 Released

Arg. Wouldn't you know that almost as soon as I post 1.0.19, I discover that in adding a feature to 1.0.19 (the compare button on the check for overwrite dialog), I broke the functionality of the overwrite dialog. In my testing, I focused on the functionality of the compare button -- worked like a charm, but didn't pay much attention to the functionality of the overwrite buttons. After all, I hadn't changed that code at all.

Wrong! Oops. Oh well. If that's the only mistake I make this year, won't I be lucky. Build 1.0.20 looks to be okay. The check for overwrite dialog behaves as it should for all the buttons now.

QVCS-Enterprise 1.0.19 Released

I just posted the 1.0.19 release of QVCS-Enterprise. It fixes the bug that some users have discovered when trying to change the user password from the client.

I don't generally like to post releases this close together... but when there is a bug that's been pending that I'm finally able to reproduce, I'm willing to make exceptions.

QVCS-Enterprise 1.0.18 Released

I posted the 1.0.18 build of Enterprise. Let me know what you think, either here or on the forums.

QVCS-Enterprise 1.0.18 break lock feature

The 1.0.18 release will also have a 'break lock' feature. Users with PROJECT_ADMIN rights for a project will be able to break the lock on any file in that project.

The next QVCS-Enterprise: 1.0.18

I'm putting the finishing touches on the next build of QVCS-Enterprise. It has several bug fixes, and adds some 'features' as well. I should be able to post the build sometime this weekend. The biggest feature additions are:

• Filter collections can now be associated with a specific project. This makes it a lot easier to manage filter collections across separate projects.
• The server now keeps an activity log. This is a human readable file that provides an audit trail of activity on the server.
• The 'get' and 'checkout' operations now ask you before overwriting a file that you may have edited.
• The client will now delete a workfile at checkin time if the 'delete workfile' attribute has been set.

As features go, these are pretty mundane, but they are the kind of things that make the product more mature and useable.

The biggest bug fixes are relatively minor client side problems:

• Fixed a problem with the exclude workfiles filter so that it now works correctly in the presence of obsolete (deleted) files.
• Moved logging for the 'Activity Log' panel to the Swing thread to avoid a possible deadlock condition.
• Fixed a problem with the algorithm that figures out the value to display in the 'File status' column.

This release marks the first use of the new version numbering scheme that I plan on using in the future. This will be version 1.0.18. One way to read this is that this is build 18 of the 1.0 release series. That's the way I read it anyway. Earlier releases had labels like 1.0.0.16. That 2nd '0' didn't serve any purpose, so I'm getting rid of it.

In fact, I'm establishing that as the new Quma worldwide version labeling policy. This new labeling policy will apply to future QVCS/QVCS-Pro releases as well.

Tweaking Enterprise

I've been spending the past several evenings cleaning up Enterprise code. I know, I know, it should already be clean... but in the real world, you wind up sometimes with something that is not as clean as you would like.

The tool I've been using to help with this mini-project is called findbugs. It's open source, and pretty useful. I can't say that it has uncovered anything significant, but it has helped me track down dead code, and other kruft that the compiler does not catch. Though I haven't yet integrated it into the Enterprise ant built script, it does have ant support so that I can automate its scanning of the source so it can catch boo boos automatically.

I found the findbugs tool at the java-source.net site. Highly recommended.

QVCS-Enterprise 1.0.0.16 published

A week late, but better late than too early, at least for software publishing.

The week's delay gave me a chance to fix some things that I should have caught earlier. As a result, this build is the best Enterprise release to date, and is much more stable than earlier releases.

In getting things buttoned up today, I ran across another bug that had been lurking since the beginning. When I create a release, I use the custom Ant task of the product to create the build. This is both a convenience, and a simple way to test the functionality of the custom Ant task. In earlier builds, the custom Ant task would usually work and I had enough other things going on that I never took the time to figure out what was the cause of the problem. This time around, I decided I'd had enough -- time to slay this inconsistent behavior.

After several false starts, I finally figured out the source of the problem: it was a race condition that would only occur if the moon aligned a certain way -- i.e. it fit the observed behavior exactly, since prior to the fix, the Ant task usually worked correctly. Since the fix, the custom Ant task behaves very predictably, and I'm a much less frustrated user.

Among the other clean up things that made it into this release, the most significant bug fix has got to be the clean up of some subtle memory leaks. The largest source of leaks was within some code that made use of the Java ObjectOutputStream and ObjectInputStream. As it turns out, both of these classes hold on to references of the objects that are serialized through the streams so that if you are serializing an object tree, the serialization plumbing doesn't have to serialize the same object more than once. This makes these streams efficient for sending an object from one place to another, but it makes for a subtle memory leak if you leave the streams open for a long time and use the streams to serialize bunches of unrelated objects.... which is exactly what QVCS-Enterprise does when sending data back and forth between the server and the client. Of course, all this is documented after a fashion -- you just need to make sure to call the reset() method on the ObjectOutputStream in order to get the stream to discard any references that it is holding on to. The code does that now; it did not do it in earlier releases.

To verify that the memory leaks have been fixed, I tested the application with a project that contained over 11,000 files. Both server and client survived, and while client performance for a project of that size is slower than I'd like, it did work, and did not suffer from an Out of Memory exception. The same can be said of the server. Prior to these fixes, neither server nor client could handle projects of that size.

QVCS-Enterprise build 1.0.0.16 will be out by November 7

Well, I had thought that 1.0.0.16 would be released by now. I was wrong.

It turns out that I had to be out of town on a business trip over the weekend, and as a result didn't have the time to wrap things up for the build.

This, in hindsight was a good thing, since it gave me some time to profile both the server and the client application. That effort produced a happy result: I found several fairly significant memory leaks in both the server and client. Those memory leaks are now fixed, making the server much less likely to run out of memory than in earlier builds.

I also had a chance to put in a new splash screen, and add some useful information to the 'About' box. You'll get to see the results by Sunday, November 7.

Preparing for the 1.0.0.16 build

I finished coding of the final 'feature' for the 1.0.0.16 build this evening. It was much easier than I had feared.

The 'final' feature is a 'nice-to-have' for enabling/disabling the server's generation of reference copies at check-in time. I added a new set of check-boxes to the new project properties dialog that is in the admin tool. This new project properties dialog allows you to enable the creation of reference copies on the server. You can also disable the creation of reference copies on the server.

The 'nice-to-have' part of this feature is a couple of added check boxes that allow you to request that the server create or delete any reference copies at the instant that you click ok on the project properties dialog. This makes it so you can change you mind about whether you need reference copies well after the project has been around for awhile.

The deletion of the reference copies is a straight forward task -- just recurse through the archive directory structure, and delete any 'reference' files in the corresponding reference file directory hierarchy.

The trickier behavior was to have the server create reference copies for the entire project hierarchy if the user is enabling the creation of reference copies on the server.

This turned out to be simpler than I had thought it would be -- much of the hard work had already been coded in order to support the revision compare feature. Suffice it to say that it took less than 30 lines of code, and less than 2 hours of work. Cool.

Don't you just love it when things work out that way?

So, I'm on track to finish things up for the October 31 target date.

Java 5 Support for QVCS-Enterprise?

I'm finishing up the 1.0.0.15 build for QVCS-Enterprise, and in the process, thought I'd give Java 5 (a.k.a Java 1.5) a whirl. Testing is nowhere near complete, and I'm not sure that I'll 'officially' support it, but I have gotten the client application to work.

Startup time is improved, as promised, and overall, the application has a snappier feel to it. For the test, I ran the client application on Java 5, and had the server still running on a 1.4.2_05 JVM. All source was built using the 1.4.2_05 compiler, so all I was testing was whether the 1.4.2 byte code would execute correctly in a Java 5 virtual machine.

The only problem I ran into was at application initialization. Apparently the Java 5 VM has a different startup sequence for loading the logging subsystem than existed in 1.4.2, or the Java 5 logging subsystem is less forgiving of null pointer exceptions than it was in 1.4.2. The 'fix' was to change the initialization code within the logging component to defer logging anything until after the main frame window has actually been created. With that minor change to just one source file, the client application is running in the Java 5 VM, talking to a 1.4.2 server. Cool.

What's in the next release

I've been targeting late October as the release date for the next build of QVCS-Enterprise.

Obviously, to hit that date, some (most?) of what will appear in that build must already have been coded. So here's a list of what is in progress or already done:

• Improved look and feel support so user can choose from several look and feel alternatives.
• Add support for reference copies on the server. This means when you check-in or create an archive file, a copy of the associated workfile will get made in a reference location on the server.
• Add support for running the server as a Windows service.
• I've done a lot of work to clean up some of the nuisances in the way the client application behaves when there is pending work on the server. In earlier builds, it was sometimes difficult to tell when the server was still processing a client request. Much of that ambiguity is now gone. I won't claim that it's yet perfect, but it is improved over earlier builds.
• In the client app, you can now change the workfile location without having to restart the client app.
• I put in a lot of changes to make sure that all the client updates occur on the Swing thread. Java developers will understand what I'm talking about.
• Fixed a client bug that caused concurrent modification exceptions to get thrown.
• Fixed a bug in keyword expansion that happened when doing a visual compare.
• System properties now get logged to the respective log files at application startup.
• Use a combo box on the label dialog so you don't have to always type in the label string.
• Several other bug fixes.

Comments are enabled.

I'm using haloscan to enable comments on this blog. Haloscan (so far) is pretty cool. You can check them out at Haloscan.

Plastic look and feel

Tonight, I took some time to take a look at the jgoodies look and feel. I'll probably go ahead and include it in the upcoming late October release since it improves the polish of the Enterprise client and is very easy to install into the code.

How to apply a label to a set of files.

When you are working in product development, you often need to apply a label to the files that compose that product. Sounds simple... you just select the files, and apply the label.

But what if there are some files present in the project -- files that you have under version control -- that are not really meant to be part of the product's set of files? How do you set things up so that you don't have to always keep track of what belongs in the project vs. what does not belong... i.e. how do you keep track of what should get labeled vs. what should not get labeled?

Some of the specifics are different between QVCS/QVCS-Pro and QVCS-Enterprise, but for all three products, the best first step to take is to apply a floating label to those files that are meant to be part of the product release.

Applying a floating label is a straight forward task -- just select the file (or files), click the label button on the toolbar, enter a label string, and make sure to enable the 'Make this a floating label' check box. With QVCS and QVCS-Pro, you can also apply a floating label to all the files that are within a project by selecting the project node, and then using the context menu to apply the label. (QVCS-Enterprise does not yet support project or directory level operations).

Once you have a floating label in place for just those files where it is required, it's a simple operation to apply a regular (non-floating) label to just those files: Select the files (or project if you're using QVCS or QVCS-Pro), apply the label -- making sure to enable the 'Duplicate this label' check box, and in the associated combo box, select the floating label that you had earlier applied.

When the labeling operation completes, only those files that already had the floating label will get the new label. Files that didn't have the floating label will be skipped.

Now you can easily create your release build by doing a 'get by label' using the newly applied label that will only be associated with the files are actually part of the product.