Saturday, June 16, 2012
More "Free Beer!"
I've decided to transition Quma from 'business' to 'hobby'... To complete that transition, I've decided to re-price QVCS-Enterprise -- it now joins QVCS/QVCS-Pro as 'free' (as in "free beer").
I'd like to thank the QVCS user community for the many feature suggestions over the years, and for finding QVCS a useful tool.
I'll still putter around on QVCS-Enterprise development... but the features I add will be to scratch my itches instead of adding features that might make the tool more marketable, etc.
Sunday, January 01, 2012
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.
Friday, November 25, 2011
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.
Thursday, October 20, 2011
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':
- 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.
- In that directory, there will be a file names qvcs.servername.your server name.properties.
Edit the QVCS_SERVER_ADMIN_PORT line to read:
Edit the QVCS_SERVER_ADMIN_TRANSPORT line to read:
- Save your edits.
- Make sure that your firewall (if you have one) has port 9888 open on the server.
- 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':
- On your client machine, go to the directory where the client application is installed. Beneath that directory, there will be a qvcsProjectProperties directory.
- In that directory, there should be a file named qvcs.servername.your server name.properties.
Edit the QVCS_SERVER_PORT line to read:
Edit the QVCS_SERVER_TRANSPORT line to read:
- Save your edits.
- Make sure that your firewall (if you have one) has port 9888 open on the server.
- 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.
Sunday, June 05, 2011
It was Italy this year...
My wife and I traveled to Italy this year for our annual vacation trip. We flew via Atlanta to Milan where we stayed for 1 night at Hotel Spadari which has a great location near the Duomo cathedral. We then took the train to the Lake Como area, where we stayed for 6 nights at Al Veluu Restaurant and Suites. They have a beautiful setting above Tremezzo -- there are only 2 suites above the restaurant. We were early enough in the season for things to be pretty quiet. It was a 10 minute walk down the hill into town. While in the area, we toured the gardens of several of the nearby villas, and otherwise enjoyed the food and scenery.
The gardens at Villa Carlotta were very impressive... we had timed the trip in hopes that gardens in the area would be in full bloom, and we were not disappointed... absolutely gorgeous. The Lake Como area has its own 'micro' climate -- they have palm trees, and cactus, and azaleas, and giant sequoia (not too giant yet), etc.... a real botanical mash-up. For a day trip, we took the bus over to Lugano, Switzerland. Who would have thought to find palm trees in Switzerland?
From Tremezzo, we took the bus to Como, where we caught the train to Milan, where we took the train to Riomaggiore -- one of the Cinque Terre towns on the Italian coast. We rented the Marco Polo suite for 5 nights. It was a great location with a great view overlooking the town. We hiked all the trails that were open (the one between Corniglia and Vernazza was still closed due to rock falls). Cinque Terra is touristy but not built up with anything particularly modern looking. It's one of Rick Steve's favorite parts of Italy, which contributes to the crowds, but also helps keep the towns in business.
We'll probably go to Greece again next year (Crete and Santorini), but this Italian iterlude was worthwhile -- it's beautiful country.
Saturday, March 19, 2011
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.
Thursday, January 20, 2011
One of my pet peeves with the English language is the use of possessive pronouns. For example, 'my' is typically used to mean ownership, as in I am writing this on 'my' computer. But what word must we English speakers use when we want to describe the relationship we have with someone else? The very same 'my' -- where now it defines a relationship instead of ownership, as in I love 'my' wife. Clearly, the relationship I have with my wife is vastly different than the one I have with my computer, yet in standard English usage, I use the same word for both relationships. This, I think is a defect of the English language. I wonder that other languages have the same defect, or if any languages don't have this particular language defect.
Friday, December 31, 2010
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.
Sunday, November 21, 2010
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.