I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

What Is The Most Popular Source Control System?

07.20.2010
| 14686 views |
  • submit to reddit

Today I want to find out what the most popular source control system is. There's a lot of choice out there, from traditional options like CVS, to distributed offerings like Git and Mercurial. I'd also like to hear some compelling reasons, based on your own experience, that would force me to consider moving to a distributed system.

Even though CVS is now considered an old technology, it's reliable and it's what I use in my day job. Seeing as CVS has never let me down, I don't feel compelled to move to distributed options. Given the quality of it's IDE integration, I assume that most software development organisations are still using CVS.

So please, choose what version control system you are using in this poll, and if you want to try and convince me to move to DCVS, feel free to try in the comments section.
 

Comments

Kevin Slater replied on Tue, 2010/07/20 - 9:16am

There is no way to convince you to move to a DVCS. But if you find a decent tutorial for Mercurial and give it a try, I think you'll convince yourself. I was firmly in the Subversion camp, but in today's world of laptops and going in and out of connectivity, I like the DVCS model much better. I've used Git and while it's solid architecturally, the user experience is not that good. Mercurial FTW!

Alex(JAlexoid) ... replied on Tue, 2010/07/20 - 9:18am in response to: Kevin Slater

laptops and going in and out of connectivity

Well, on the other hand some people live in areas of omnipresent connectivity and have no issues with Subversion.

Liran Mendelovich replied on Tue, 2010/07/20 - 9:54am

Mercurial. It's fine, but I have problems with merges. Would not say I recommend it, but don't know if it's better than other choices or not.

Liran Mendelovich replied on Tue, 2010/07/20 - 9:59am in response to: Kevin Slater

I wrote myself a Mercurial getting started guide, intended for using with Eclipse plug-in. It's not in english, but I can translate it. People are interested in this, so i'll publish it ?

Eyal Golan replied on Tue, 2010/07/20 - 10:02am in response to: Liran Mendelovich

Please do :)

Liran Mendelovich replied on Tue, 2010/07/20 - 10:04am in response to:

OK, i'll do it. I hope it will be fast.

Gerald Varas replied on Tue, 2010/07/20 - 11:02am

We use PVCS VM, and it's fine for our requirements!

Philippe Lhoste replied on Tue, 2010/07/20 - 11:30am

We use Perforce at work (a fine VCS, with good GUI support) and I use Bazaar at home (easy to use and very flexible, working well on Windows).

 If you want to look what advantages DVCS can have over centralized VCS, maybe Hg Init: a Mercurial tutorial site can be convincing... :-) It pits SVN against Mercurial, giving, of course, the latter as winner! The author is a bit partial as its company made a tool around Mercurial, but it is still interesting to read. Note that what is written about Mercurial is of course true for other DVCS tools like Bazaar or Git.

One thing well handled by Bazaar and now Mercurial is renames (and moves), making them superior tools for refactoring.

Jilles Van Gurp replied on Tue, 2010/07/20 - 11:48am

You'd definitely be ahead of the curve switching to a DVCS right now. Not doing so, however, means missing out on the many benefits.

Using CVS means you're a definite behind the curve type. Does that matter? Well probably you are either wasting a lot of time on using it properly (e.g. branching/merging, refactoring and renames, collaborating effectively) or not using it much at all. I.e. missing out on most of the advertised benefits of version management. Effectively using it as a glorified file server. In the former case I pity you for your misery, which is so unnecessary given 2+ decades of technological progress relative to CVS. In the latter case I pity your co-workers.

You might argue you don't proper version management. But I'd argue you have probably no clue about what you need in this (and other respects).

So moving on ...

Should you switch to a dvcs and more importantly should you switch now? Given that you are the behind the curve type, the answer is no. You wouldn't be able to handle the transition. You're a follower, not a leader. It's beyond you. There are definitely a lot of benefits to switching but you are unlikely to notice them and very likely to bitch and moan about the relatively experimental status of most relevant software out there (e.g. git integration in eclipse is relatively new). It's unlikely to suck more than CVS though.

But instead switch to Subversion right away. It's proven technology, well supported and anything is better than CVS. CVS stopped being a good choice long time ago. Subversion is enough of an improvement that it is worth the trouble.

Kevin Slater replied on Tue, 2010/07/20 - 2:07pm in response to: Alex(JAlexoid) Panzin

True enough, connectivity is pretty ubiquitous nowadays. However, I still find times when I appreciate having the ability to check in code locally or do a branch for some experimental work. I'm not knocking SVN, it's a fine tool, but I've come to same conclusion that Linus Torvalds has and with which he challenged the Google engineers: namely, if the major issue with your SCCS is lack of proper tracking for merges, why would you pick a tool that didn't improve that facility? (He was speaking of moving from something like CVS to SVN.) That is one feature (mentioned by other below) that I feel Hg has over Subversion - not just painless branching, but painless merging.

Alex Forbes replied on Tue, 2010/07/20 - 2:42pm

Most popular for ______. If you narrow this question down to the problem you are trying to solve, you may get much different results. For distributed teams doing parallel or Agile development, I would choose Accurev hands down. For a 10-person shop doing mainline development, SVN, and in some cases, still Accurev.

John J. Franey replied on Tue, 2010/07/20 - 8:03pm

I think you can continue using cvs until it lets you down. Its not a matter of 'if' it will let you down, its a matter of when. Its a workhorse, reliable, and predictable, until its not. Basically, I don't think you have been using cvs long enough, or with enough frequency of use, or with enough users, or with enough projects, or with enough files.

One day about a year ago, about 4 of us in the project team spent about two hours talking about how to rollback a series of premature commits from about a week back which were not tagged, of a project with over 6000 files. Once we worked out a strategy, it took about a day for one of us to pullout the unwanted code, and another day of testing. CVS let us down that day. With git the whole thing would have been over in 10 minutes.

Have fun.

James Sugrue replied on Wed, 2010/07/21 - 12:59am in response to: Liran Mendelovich

Yes - it would be great if you published it. Feel free to post it here on JavaLobby.

James Sugrue replied on Wed, 2010/07/21 - 1:01am in response to: John J. Franey

That's exactly the kind of use case that I'm look at finding a solution for, having had those experiences with CVS. What does Git have that would have made that easier for me?

Liran Mendelovich replied on Wed, 2010/07/21 - 2:34am

Already did it. It's on the way, look for it later :)

Liran Mendelovich replied on Wed, 2010/07/21 - 3:03am in response to: James Sugrue

With Mercurial, you just do "switch to" option - and you go back to whatever previous revision you want. No 10 minutes, but 10 seconds ( I had experience with it on 60~ files project, no more, so I only say it according to my experience). It's not perfect though. My Mercurial guide should be published soon by this site. And as for IDE integration you mentioned - With the Mercurial plug-in for eclipse, it's very simple for everyday use.

Mladen Girazovski replied on Wed, 2010/07/21 - 3:22am in response to: James Sugrue

That's exactly the kind of use case that I'm look at finding a solution for, having had those experiences with CVS. What does Git have that would have made that easier for me?

As mentioned before, if you branch and merge, CVS is a PITA.

If you refactor, CVS will simply let you down, since changes to packages/folder names means you loose your history.

Also, as mentioned before, if you don't use these features, you won't have any benefit from a modern tool.

And - this has also been mentioned before - if you plan to use these features, moving from CVS to GIT is probably not the best idea, use SVN first before moving on.

Reversing changes in SVN? Copy the old revision to the head and you're done.

Liran Mendelovich replied on Wed, 2010/07/21 - 10:12am

Well here is my Mercurial Guide: http://java.dzone.com/articles/mercurial-guide

Gregory Smith replied on Wed, 2010/07/21 - 12:57pm

We are using SVN on all of our newer projects (some of the old projects still use CVS), so I clicked the SVN radio button when I voted. But if it were a question of what I would prefer to use rather than what I am actually using, I would vote for git. I am not surprised to see that it is now the second most popular source code control system, ahead of CVS and Mercurial. It is what my company ought to be using, but unfortunately I am not the one making those decisions.

John J. Franey replied on Wed, 2010/07/21 - 3:09pm in response to: James Sugrue


# show commits on master (git's HEAD) branch.
# git's log output is piped by default through a pager, cvs log isn't.
# git's log is project oriented, cvs log is file oriented.
#    log output is much easier to consume in git than cvs which would
#    show all commits of a single file before showing commit log of the next.
# git's commits have unique identity, cvs's do not
# the following would display all commits on a branch and
# by paging down with space bar the offending commits could easily be identified.
# FYI: git log also has options for filtering, say by user, which could be useful.
# as it is here, identifying the offending commits would take about 2 minutes, if that.
# (almost  all of that 2 minutes is due to the response time of your brain, not git)
git log

# git revert creates changes that reverse the changes of the commit.
# (I am not remembering anything comparable in cvs).
# I don't remember if revert would leave conflicts that need to be manually resolved.
# If there are no conflicts, each of these would take roughly a few seconds.
git revert commit3
git revert commit2
git revert commit1

# or this might work:
git revert commit1 commit2 commitN ...

# then test and party.

John J. Franey replied on Wed, 2010/07/21 - 3:38pm in response to: Mladen Girazovski

And - this has also been mentioned before - if you plan to use these features, moving from CVS to GIT is probably not the best idea, use SVN first before moving on.

I've used cvs (6-8 years), svn (2-3 years), now git (2 years). I disagree with this recommendation, and this is a matter of opinion, I know, so I do not mean to take anything away from Mladen. I used svn in the days before 1.5, which brought 'merge tracking', and I think some sort of unique object identity (?). Maybe its better, I won't know.

My opinion is when talking about the everyday commands required to be functional, the learning curve to git/mercurial from cvs is little more than the curve to svn from cvs. checkout, commit, branch, merge in the abstract are the same for all, with syntax the differentiator. git/mercurial won't be fully grokked until the data model is understood. The data model has what: 4 object types? Not much of a cognitive leap. Also, a novice should pay close attention to the distribution of repositories; maybe an additional 2 hours of study over svn. My point is, the learning cost is not high enough to shun git/mercurial for svn.

The return on the learning investment is much bigger for git/mercurial than for svn. That I'm positive about. This depends on the network latency between your workstation and the candidate subversion host. For me, a checkout across the network would take 20 minutes at a time. With git, a checkout would take a half moment. In other words, unless your network latency is within the same range as filesystem latency, svn (and cvs) is quite literally a waste of time. git/mercurial will give that time back to you.

Reversing changes in SVN? Copy the old revision to the head and you're done.

And this would lose the commits that were made on top of the offending commits. git's revert command won't. (mercurial probably has the same).

Regards,

John

Mladen Girazovski replied on Wed, 2010/07/21 - 5:30pm in response to: John J. Franey

John, i find it more than hard to disagree with your statements, since personally i simply don't disagree.

However, i found it really hard to convince "silverbacks" to use SVN in a non-CVS way, that is, creating branches & merge them back to other branches (i.e. trunk).

So, take my statements merely as a suggestion of how to transistion from using minimal SCM  (as with CVS) to using a  SCM properly, soon people would find the gaps in SVN once they are comfortable with it.

In my experience people don't apprececiate changes (even developers, unless they're really in to it), often bigger changes will fail not because of the technology used, but because of the existing culture (or lack thereof) at the company/department/shop.

Just for reference, when i earlier said "as mentioned before", i was refering to Jilles van Gurps post.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.