Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #10619
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Two More Very General Consulting Question |
| References | (3 earlier) <sdrud79e4044ni5uv0tnlna41q3eo890oh@4ax.com> <alpine.DEB.2.00.1112071851130.1589@urchin.earth.li> <4edffd56$0$286$14726298@news.sunsite.dk> <mBTDq.11783$cG.7766@newsfe14.iad> <alpine.DEB.2.00.1112081541440.15036@urchin.earth.li> |
| Message-ID | <SMlEq.17211$JE1.11242@newsfe21.iad> (permalink) |
| Organization | Public Usenet Newsgroup Access |
| Date | 2011-12-09 06:53 -0400 |
On 11-12-08 12:04 PM, Tom Anderson wrote: > On Wed, 7 Dec 2011, Arved Sandstrom wrote: > >> On 11-12-07 07:57 PM, Arne Vajhøj wrote: >>> On 12/7/2011 1:58 PM, Tom Anderson wrote: >>>> On Wed, 7 Dec 2011, Roedy Green wrote: >>>>> see http://mindprod.com/jgloss/subversion.html >>>>> http://mindprod.com/jgloss/tortoisesubversion.html >>>> >>>> I would say that in this day and age, it is no longer appropriate to >>>> suggest Subversion. Subversion was the best tool available for a >>>> long time, and it is still perfectly serviceable, but there are >>>> better tools available now; projects using it can keep using it >>>> without worry, but there is no reason for a new project, or a >>>> project adopting a new source control system, to start using it. >>> >>> VCS is an area where fashion often seems to overshadow >>> facts. >>> >>> Today with hg and git then SVN is suddenly so oldfashioned - you can >>> not use a non-distributed VCS without being considered stone age. >>> >>> The distributed part is great for code that is being worked on by >>> completely independent organizations (read: large open source projects). >>> >>> But most people do not really have that need. >> >> I'm with you on this, Arne. You beat me to it actually. 100 percent of >> the version control scenarios that I have encountered in business in >> over a decade require a "central" or "master" repository and an >> official keeper of the flame. Branches have to be strictly decreed and >> controlled, lest anarchy result. If git or Mercurial were used in >> place of SVN, the manner in which they'd have to be used would offer >> zero benefits over SVN. >> >> I agree that there are plenty of scenarios that benefit from a >> distributed VCS. But a whole bunch don't. > > Incorrect. Have either of you actually used a DVCS for any length of > time on a team project? In order to acquire facility with Mercurial and Git I use them myself, on my own work (which may be real work, but doesn't involve anyone else). I've used Mercurial for about 3 years, have used Git less and maybe for about 2 years. I haven't done any open source teamed projects within the past few years. There have been zero opportunities to use Mercurial or Git on the job, *with a team*. I have actually tried, three times in as many years, to make one or the other happen. > It's true that a great many projects don't need the anarchic > fully-distributed mode of operation that DVCS allows. In fact, the only > one i know of that really uses it is the Linux kernel; even other open > source projects using DVCS have a fairly centralised workflow. > > But the thing that DVCS gives you that is invaluable to everyone, > everywhere, is local commits. You can work, commit, work, commit, work, > realise you've gone wrong and roll back to your last commit, work, > commit, work, have an idea, commit, try something experimental, learn > something, roll back to your last commit, work, commit, and so on. All > locally, without having to push up to the server, make a zip file, make > a patch, or do any other monkeying about. All inside the version control > system. > > It is a massively useful thing to be able to do. Tom, no need to sell _me_, I am sold already. :-) That's why I have tried three times in as many years to introduce a DVCS in a real work environment. Each time it's been a SVN shop (which is part of the problem, they've already got SVN). I'll tell you why it's failed: 1. It's (legitimately) hard to convince a client that a centralized DVCS model is significantly better than a SVN setup. It has to be _significantly_ better because they are facing a migration of history [1]; 2. Very few arguments that have to do with benefits for _developers_ are important. You don't have to convince developers, you have to convince managers. 2. Only the developers amongst the client personnel understand your "local commits" argument, or the other one (better branching/merging than SVN). Problem is, very few of the managers get it, and _they_ are the ones that need to be convinced. I've encountered my share of client managers that actually don't see your description of local commits as being a good thing, unlike you or me or most developers. To them that all sounds like coders wasting time at best, and unsupervised work at worst. > Arved mentioned that "branches have to be strictly decreed and > controlled, lest anarchy result", and that's true, but with one > qualification - it's true of branches *on the server*. People can make > whatever branches they fancy locally, as long as they don't trouble > anyone else with them. That can be useful too, on occasion. > > My team moved over to Git a while ago. We have a traditional centralised > workflow: we work locally, and push and pull to a central server. We > don't push and pull to each other. Even for us, a DVCS has been a great > tool. > > Even if you don't make use of the new powers bestowed on you by a DVCS > (which would be a great mistake), the current crop of DVCSs offer > evolutionary improvements on Subversion. They don't need a server, so > they're easier to set up and manage. They make creating new repositories > much easier. They're faster. They are, incredibly, usually more compact > (a Hg/Git repository + working copy is usually smaller than a Svn > working copy alone - recall that Svn stores a pristine, uncompressed, > copy of each and every file). They don't litter your working copy with > millions of secret directories. > > The only downside is that the graphical tools, and integration with > other systems, is not always as good as for Subversion. But note that > "not as good" means "80-90% as good". I use Git and Mercurial through > their Eclipse plugins, and they are basically as good as the Subversion > or CVS plugins. They each have a few warts, but they are purely cosmetic. > > So, no, the noise about DVCS is not fashion. It is firmly grounded in > facts. > > tom Again, _I_ agree with you 100 percent. But Tom, if you read what I originally wrote, I referred to "business scenarios that I have encountered", "the manner in which they'd have to be used", and things of that nature. I wasn't referring to technical superiority of hg or git over svn, or lack thereof, or vice versa. In fact I'm satisfied that hg/git are always at least as good as svn, and usually better. It's simply that I have yet to encounter a team environment where the managers bought this. I've made three attempts in as many years; everyone else I've worked with in the past 5 years, say, would have been as difficult to convince as those three teams. And bear in mind that quite a few of the arguments in favour of DVCS, unless pitched very carefully (and sometimes de-emphasized), either don't interest managers, or they don't like what they hear. I've also encountered a couple of organizational version control types who have to be carefully talked to so they don't feel threatened by "developer empowerment", and once you've semi-successfully done that then they don't care enough about DVCS to be champions either. Let me put it this way, and maybe this helps to make my point: "they make creating new repositories much easier", as you mentioned above, is _not_ a selling point in many client environments. There is zero appeal to many managers of developers being able to make repositories, and there can be substantial pushback to features like this. To many managers the features of DVCSs that you or I (or other with-it developers) like are negative selling points, because they interpret those as leading to lack of control and lack of visibility. Sooner or later I'll succeed in getting a client organization interested, and interested for the right reasons. But it hasn't happened yet. AHS 1. History is super-important in these organizations. It is how you locate scapegoats.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 21:00 +0000
Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-30 21:45 +0000
Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 23:00 +0000
Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-01 03:06 +0000
Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-12-06 15:24 +0000
Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-06 20:59 +0000
Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:45 -0800
Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-07 18:58 +0000
Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:57 -0500
Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-07 20:33 -0400
Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-08 16:04 +0000
Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-09 06:53 -0400
Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 12:51 +0000
Re: Two More Very General Consulting Question Lars Enderin <lars.enderin@telia.com> - 2011-12-09 17:26 +0100
Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-09 23:12 +0000
Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-10 12:00 +0000
Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 19:53 +0000
Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-11 00:04 +0000
Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 20:12 +0000
Re: Two More Very General Consulting Question Jim Janney <jjanney@shell.xmission.com> - 2011-12-12 03:05 -0700
Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-12 06:39 -0400
Re: Two More Very General Consulting Question Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-07 20:55 -0600
Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 10:42 +0000
Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:48 -0500
Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:43 -0800
Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 20:15 -0500
Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-06 16:45 -0800
csiph-web