02/02/2012 10:12:59 AM EST
It's a shame that Mr. Rubenstein feels he must twist words and context to create the illusion of controversy, leaving those he purports to quote to clean up the mess. Please allow me to clarify the statement attributed to me, which in its original form would have been about Subversion's destiny (and nothing more).
The Subversion developers have no plans to transform it into a DVCS tool. The market still needs centralized VC, and Subversion is the best offering in that space. And if, some day, DVCS emerges as The Only Way To Do It, then there would still be no need for Subversion to adopt that model because several great DVCS tools already exist.
United StatesC. Michael Pilato
02/06/2012 03:14:16 PM EST
At my company, we use subversion to do all our centralized version control, but I have started using Mercurial to interact with it. Mercurial supports a plug-in called hgsubversion that allows me to clone a subversion repository into a local mercurial repository. I then make all my commits locally.
When I feel the need to share those commits with the others on the team, I then "push" my local commits to the subversion repository. And when I need to get other's changes I can "pull" them from subversion repository into my local mercurial repository.
I have the best of what both DVCS and CVCS have to offer!
United StatesJack C. Holt
02/06/2012 03:38:03 PM EST
Front-end closed-source web apps are reverse-engineerable anyway. Enterprise dev may as well use Git and enjoy the DVCS benefits, like open-source, accept pull reqs. But how do teams inexpensively manage the server-side "security-inside" 'secrete-source' code?
United Statesclive boulton
02/06/2012 11:58:01 PM EST
This is a pretty revisionist history. Branching forbidden before 2000? I wonder what I was doing in ClearCase for all those years?
03/21/2012 12:42:44 PM EST
I disagree with the overall theme of the article that client-server (aka '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 make it arcane. remote development? Not true, replicas, remote logins, web-based access all facilitate remote development. No flexible release cycle? Wrong again. Many companies are using CI and agile using 'yesterday's SCM systems".
It sounds like yesterday's tools can't do agile period, and only DVCT's can, which is wrong.
United StatesMarc Towersap
03/22/2012 01:17:01 PM EST
I agree with most of the previous commenters. The author seems to equate fast/flexible branching & 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 90s with commercial tools. There just werent any popular open-source tools that did it as well until Subversion (and later Git) entered the 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-sources and commercial tools) these days support fast and flexible branching and merging. That issue is very different from the centralized vs decntralized 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 P4Copy) into their systems, and/or implementing capabilities that allow treating an SVN sandbox or Git repo as a "local client" that it can accept changes from as per configured policies.
The industry-wider 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 setup 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.
United StatesBrad Appleton
Copyright © 1999-2013 BZ Media LLC, all rights reserved. Legal and Privacy
Phone: +1 (631) 421-4158 • E-mail: email@example.com