I'm consulting an unnamed high-tech company where someone once decided that it would be a good idea to pay millions of dollars a year for the second-worst version control tool in existence (the worst is called "no version control at all"). I don't mind company A being arm-deep in company B's pockets but I do mind the fact that the developer's life in company B is made a living nightmare.
For example, how long a time would you consider a reasonable wait for a seemingly simple operation such as "show me the version control status for all four text files in directory X"?
How does 30 seconds sound to you?
Enterprise?
Very.
Not to mention that it takes 4 commands to add a file or a folder under version control from the command line.
*Sigh*
Fortunately we've been able to adopt Subversion on some projects and there is some movement within the organization to make Subversion an officially supported version control system.
I'm sorry, Joe.
The EULA on that product is likely saying something along the lines of me getting beheaded if I say anything bad about it in public. And I don't like the idea of getting beheaded by a large, multi-national software and hardware vendor in the habit of buying out smaller large software companies ;)
Oh, and I just realized that it's probably not the second worst but the third worst product out there. (I had completely forgotten Visual SourceSafe existed...)
Oh, right. I forgot the CI part altogether.
The old version of the product was indeed possible to integrate with CruiseControl (although not quite as easily as CVS or SVN, for example) but the new version is apparently not that friendly. I believe there's been some effort doing just that but so far without success...
Beyond having a CI server, this particular product makes CI in general nearly impossible simply because it takes so much effort to share your changes with the rest of the team. With Subversion you can do a full edit-merge-commit cycle in a matter of a couple of minutes whereas with this POS it takes a couple of minutes to just do the checkin operation and you have to effectively checkin twice because the setup enforces the use of private integration streams in addition to private development streams. Pure overkill for my way of working and nowhere near what I would call continuous integration.
- Check-in your code to the branch.
- Update the code in your branch to that it reflected the head of the trunk.
- Perform your integration tests.
- Check-in/merge from your branch back onto the trunk.
One great thing about the commercial products we complain about! They generally pay alot of money to help dig people out... If we as a profession where 1/2 competent, we'd only make 1/2 as much as we do today. Like open source is any better.... Go take a peak at OpenSSL... start by looking at the details of how to build it... look at the configure script, and then look at the code... Sheeeesh-ka-bob it's like holding back the ocean!
As a profession we create a lot of great results... it's just whats under the cover and how we arrived that ain't too pretty.
Did you happen to see the article in the Economist that displays a graph of the number of people writing code over the last number of years for Apache.org. The number has only increased a trickle... Those folks, and folks that belong to communities like that are the ones that have the largest impact on HOW we develop software these days. From a Java perspective, looking at both Eclipse.org and Apache.org and their influence on our day-to-day work style and work flow is huge. Those are the people that need to be influenced to look at problems differently... And it ain't to pretty of a future...