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.

Examining Whidbey C++

I was catching up on some reading, and discovered an interesting article on the changes that Microsoft is putting in to their version of C++ for the upcoming 'Whidbey' release of Visual Studio (a.k.a. Visual Studio 2005). The article by Richard Grimes, (which is not available for free online), is in the December issue of Dr. Dobb's Journal. I won't go in to the gory details here, but, suffice it to say, these language changes look like Microsoft is trying to force all development onto C#, or their other managed code languages.

One of the virtues of C++ has been its general platform portability. These changes make it look like Microsoft is attempting to do to C++ what they tried (and failed) to do with Java.

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.

Simple tools

Some tools which do useful things are difficult to learn and use. A possible example is Rational Rose. I haven't used it in several years, so perhaps it has since improved. But if it has become even more feature rich than it was back then, then it is only useful to that small population within the developer community who do nothing but use it. For the bulk of the developer community, it is shelfware.

In my experience, most developers are a Jack-of-all-trades. As a project begins, the developer participates in framing and defining the requirements; as the project rolls on, they are even more closely involved in design, and then implementation. This is especially true in the newer 'Extreme Programming' shops. As the work flows between requirements, design, coding, test, and deployment, the toolset varies. A developer juggles among the tools of the trade, needing to be fluent in a variety of tools. Tools that are easy to use are preferred because the developer does not have the time to invest in learning to use a complex tool. Tools that are hard to learn or use will be adopted by a small class of experts, and ignored by the rest of the developer community. In addition, complex tools will only survive in development shops large enough to justify the division of labor that allows complex tool specialists. For most shops, only a tool that a developer uses every day can afford to have any level of complexity. IDEs can succeed as complex tools because the developer is often immersed within the IDE provided environment for most of the day.

Version control tools are generally not used to the same level of intensity that is associated with an IDE. As a result, for the vast majority of developers, a version control tool must be very simple to use -- the average developer simply does not have the time to invest in learning a complex tool.

For this reason, among others, QVCS aims very squarely at the 'easy to use' target, and is purposely simple minded both because it makes it easier to write and maintain (for me), and because an 'easy to use' tool will be one that is actually used. For the vast majority of development projects, the QVCS product family supplies the functionality that's required. For the projects that require a broader feature set, those projects can afford the 'class of experts' staff to navigate the complexities that these more capable tools impose on their users.

This 'simple to use' constraint also helps explain why I've been slow to add more advanced features into QVCS. There are many features that are still needed in the QVCS family -- better branching support (for example). The challenge with these more advanced features is to add the feature yet still retain the ease of use that is absolutely vital for QVCS to be a success.

Back from Florida

I'm back from our annual Christmas trip to Florida. I was curious this trip to see what remained of the damage from the multiple hurricanes that hit the area (West Palm Beach) this past hurricane season.

Happily, South Florida has recovered pretty well from the hurricanes' effects. There are still homes with blue tarps on their roofs, and still places where there is a lot of debris. But things are close to normal. One nice thing (for us at least) was that traffic was not as bad this year as it has been in years past. In any case, it's good to be back home.

Since back, I've begun dressing up the web site that is bundled with the QVCS-Enterprise Server so that it will have a look similar to the Quma web site. Look for that in the next Enterprise build (I haven't decided on a release date).

For grins, I created my first poll on the Quma forum web site. The idea is to get some feedback on what missing QVCS/QVCS-Pro features are most important to users. It has not been much of a success yet -- only a single vote. Perhaps the vote total is so low because the products are already feature rich enough for most users? More likely the vote total is so low because as many people read the forums as read this blog.