I always enjoy reading SD Times to see what is new and innovative. However, in the real world of business, these two traits do not often carry much weight. I was very happy to read this very opinion in last issue’s opinion page (“HTML5’s next-generation browser wars”).

While using the latest technology is great for exercising your mind, it can become obsolete, leave you with code that is no longer supported, or, worse, leave you with code written in a technology that no one can maintain. For existing companies, they need technical answers to problems now; these solutions need to be in place for a long time.

Your platform for rapid application development can be FileMaker, Access or REALbasic. These solutions all can offer long-term solutions developed in a timeframe short enough to produce meaningful software. The key is proper development and understanding of the business problems.

Let’s hope you put your money where your mouth is in future issues when you say, “If you want reliability and compliance, the proprietary RIA platforms are still the best choice.” I hope to see more coverage of these real-world solutions.

Jerry Salem
IT Solutions Consulting

Old tools can get agile done
I disagree with the overall theme of the article (“Branching and merging: the heart of version control”) that client-server (a.k.a. “yesterday’s SCM systems”) cannot support agile/parallel development, which is absolutely wrong.

I’ve implemented ClearCase branching schemes to support both parallel and agile, and I’ve seen others do the same. Broken builds? That’s the world of waterfall, and again, you assume everyone works on the main branch, which is not necessarily true if you design your branching schemes correctly. Arcane branching patterns? Only if it makes it arcane. Remote development? Not true: Replicas, remote logins, and Web-based access all facilitate remote development. No flexible release cycle? Wrong again.

Many companies are using continuous integration and agile using “yesterday’s SCM systems”. It sounds like yesterday’s tools can’t do agile period, and only DVCTs can, which is wrong.

Marc Towersap
ReleaseTeam

Getting a handle on DVCSes
The author (re: “Branching and merging: the heart of version control”). seems to equate fast/flexible branching and merging capabilities with decentralized version-control systems (DVCSes). This of course is not the case at all, and many thousands of organizations and tens of thousands users were doing it in the 1990s with commercial tools. There just weren’t any popular open-source tools that did it as well until Subversion (and later Git) entered the scene. (Oh, and lets not forget BitKeeper and Arch, which were the original DVCSes long before Git).

Both SVN and Git (and many other open-source and commercial tools) these days support fast and flexible branching and merging. That issue is very different from the centralized vs. decentralized issue. That often has to do more with security and control (which definitely causes friction against the flow of development).

The author is correct that vendors are sitting up and taking notice about Git and other DVCSes. They are noticing that even in large organizations the trend is to be more collaborative and less command-and-control, so they are either implementing some DVCS capabilities (like Perforce’s p4 copy) into their systems, and/or implementing capabilities that allow treating an SVN sandbox or Git repo as a “local client” that can accept changes from configured policies.

The industry-wide trend at this point is not strictly toward DVCS instead of CVCS, it is to be able to use them together so that some centralized control and policies can be more easily set up and secure at the enterprise level (and in the cloud), while still allowing distributed peer-to-peer collaboration from distributed “agents” (be it a “client” or a DVCS rep) to higher levels of integration across a larger product or system with multiple independently collaborating partners.

Brad Appleton
United States