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.

Are Experts Experts?

I've got a theory that the actual value of development advice is inversely proportional to the amount of time its proponent has to act as its advocate. If the advocate has lots of time to beat the drum for their point of view, it means they aren't spending a lot of time actually using the tools or approach that they advocate. Conversely, actual practitioners know what works, but very few have the time or take the time to describe what works.

This very rough analogy comes to mind. Suppose you are a soldier whose task it is to 'take that hill' (or whatever). Your platoon includes a sergeant, and an embedded reporter. The embedded reporter is very articulate, and writes well crafted stories about your situation. The sergeant is not very articulate, but has been doing the soldier gig for a long time, and knows what he's about. Whose advice on soldiering is more useful to you, the soldier? Are you willing to bet your life on soldiering advice from a reporter?

Advice from people who are writers first, and practioners second are plentiful, but not nearly so valuable as advice from people who are practitioners first, and writers second.

Gotta run.

Longhorn and Detroit II

So I don't 'get' Longhorn. What does that have to do with Detroit?

Back in the 1970's and 1980's, Detroit's automakers were under the first assault by the Japanese. We lived in Michigan at the time, and things there were bleak. I remember driving through Flint, Michigan and seeing every other house for sale.

How did the U.S. automakers get blind-sided by Toyota, and Japan, Inc.? I think a lot can be explained by the insular nature of the Detroit auto scene. When we drove around in Michigan, we had one of the very, very few non-U.S. manufactured cars. Everything else on the road was domestic, made in Michigan. Meanwhile, in the rest of the country, Japanese cars were selling like hotcakes. The Detroit manufacturers didn't know anything else about cars than what they learned from eating their own dogfood, so to speak.

That turn of phrase is a nice segue to Longhorn and its relation to Detroit. For years and years now, we hear from Microsoft how they run their business by eating their own dogfood. I can sympathize with this sentiment. It's something that I do on a daily basis with QVCS. However.... The lesson from Detroit is that it's real important to get out of that rut once and a while and taste the competition's fare. As it relates to Longhorn, it seems to me that Microsoft has been living in the Microsoft echo chamber for way too long, and have talked themselves into thinking that Longhorn is a great idea. You get the feeling sometimes that they are more interested in positioning themselves to collect the Microsoft 'tax' than in positioning themselves to serve their customers. Their kind of success necessarily breeds unwarranted confidence. Didn't IBM once fall victim to this kind of thinking?

Don't get me wrong. Microsoft still produces some great products and tools. But I've been working with both Microsoft tools and Java tools, and I've gotta say that Microsoft really needs to get out of the Microsoft ghetto to see what else is out there, or they'll earn the same fate as Detroit.

Longhorn and Detroit I

What a beautiful day -- at least for mid-February. Temperatures here (the Baltimore area) today are in the upper-50's (Fahrenheit). I just got back from taking a walk around the neighborhood. The snow is almost all gone. Spring is just around the corner.

I did get around to posting the 3.7.15 release this past weekend. It's primarily a maintenance release. Take a look at the new large toolbar buttons. My local graphics consultant (my daughter) fixed them so they are nice and sharp, instead of the blurry mess that they were.

After reading about the direction Microsoft is taking with Whidbey C++, I ran across another series of articles on Microsoft's Longhorn in MSDN Magazine. I guess I'm not drinking the Microsoft Kool-Aid anymore. I don't understand the motivation for Longhorn. It seems to lack a specific focus. What's the 'big idea' to wrap around Longhorn? Why would I rewrite my applications to take advantage of the Longhorn platform? I don't know, and it appears that Microsoft doesn't know either, or at least they haven't hit their stride with the message yet.

QVCS/QVCS-Pro 3.7.15 Coming Soon

I'm putting the finishing touches on a minor release for QVCS/QVCS-Pro. The release will address these issues:

• Added support for 'Out-of-date' status to the SCC/IDE .dll. This means that IDE's that provide some indication that a file is 'stale' will now be able to show if a file is 'out-of-date' -- which means that someone has checked in a revision that is newer than the workfile that is being used within the IDE.
• There is now a 'Compare' button on the dialog that appears when QWin has discovered that you are attempting to overwrite an existing workfile that is already not write protected. This will make it easy for you to make sure that you're not overwriting something important.
• Fixed the large button toolbar to be less blurry.
• Fixed the large button toolbar so that it does not hide the named file filter combo box.
• Prevent rename requests from succeeding unless the user is on the access list for the given file.
• The toolbar compare will now compare the workfile located in the checkout location instead of the default workfile location.
• Checkin timestamps are now no longer necessarily evenly divisible by 2.

The current plan is for this 3.7.15 release to appear before the end of February.