11

I have some friends that are potentially interested in learning to use a version control system for our upcoming master theses (Latex document and various programming). I'm not talking about anything huge and complicated here, just to use it for backup, looking at old revisions and some basic branching and merging.

However, I think it's a good idea to choose one that's somewhat easy to learn for a beginner. So the question is, which version control system would you recommend to someone that's new to such things to learn?

Personally I've been using Git and Mercurial a bit and at the moment I think I'm leaning towards Mercurial. I haven't tried Bazaar though.

So far this is my impressions on features suitable for new users:

Mercurial

Pros:

  • Revision numbering
  • Easy to checkout an old commit, work on it and merge it in
  • Easy merging directly with a mergetool
  • Easy branching (?)
  • Nice plugins like glog

Cons:

  • Branches and bookmarks can both be used for what Git calls branching - could be a bit confusing
  • Doesn't give much information about what's done/wrong when a command is executed

Git

Pros:

  • Full control (gives the impression of it at least)
  • Detailed help and information when something goes wrong

Cons:

  • Some difficult concepts (like the staging area)
  • Some branching operations can be a bit difficult

Bazaar

Haven't tried it...

What do you think? Please follow the good subjective guidelines here when answering.

Community
  • 1
  • 1
Paul
  • 4,239
  • 6
  • 28
  • 29
  • I notice you have some Pros for Mercurial that you conveniently left off of the Git list. Biased much? – Lily Ballard Jan 20 '11 at 23:09
  • 1
    @Kevin: Paula pparently want's this question to be a community wiki, so go ahead and edit it adding your own pros/cons ;) – Mchl Jan 20 '11 at 23:17
  • I don't think we should work on that Pro/Con list together, as it is quite biased from the beginning. A simple important feature list would be better, but I doubt it really does matter for this question. – poke Jan 21 '11 at 00:33
  • The most important advantage of git -- its [unique local branching model](http://whygitisbetterthanx.com/#cheap-local-branching) -- is strangely missing from most of the pro/con lists I have seen on the topic. But this feature alone settles the case for me -- I couldn't do without any more (at least I would not want to). – Sven Marnach Jan 21 '11 at 02:01
  • Possible duplicate: http://stackoverflow.com/questions/4420566/scm-choice-for-a-new-user – Rudi Jan 21 '11 at 07:35
  • 2
    @Sven: hg supports the same type of branching. Just go back to any revision and commit. – Wim Coenen Jan 21 '11 at 10:29
  • @Wim: From the page linked above: "You can find ways to do some of this with other systems, but the work involved is much more difficult and error-prone. Git makes this process incredibly easy and it changes the way most developers work when they learn it." When I tried hg some years back, I had the same experience. Maybe things changed meanwhile. (And of course the linked page is not exactly unbiased...) – Sven Marnach Jan 21 '11 at 14:49
  • 2
    @Sven: As far as I can tell, there is nothing difficult or error prone about `hg update -r `, making some changes, and `hg commit -m "branched!`". The author probably thinks that `hg clone` is the only way to branch. The suspiciously long time he recorded for "branching" in his performance numbers seem to confirm this. – Wim Coenen Jan 21 '11 at 22:13

8 Answers8

10

The last few people I've taught revision control from scratch has been with git (including my daughter when she was about 12). I've also taught new users mercurial.

For someone with no revision control experience, both were equally easy. For someone broken by subversion or CVS, git was initially harder (though depending on their willingness to understand the fundamentals vs. blindly make things work, git was quite easy).

Based on that, and some of the other responses here and my own personal bias, I think git is the best answer. There are nearly two million git repositories on github alone. It's not going anywhere soon.

Dustin
  • 89,080
  • 21
  • 111
  • 133
  • 3
    Altassian's BitBucket and Canonical's Launchpad also indicate neither Mercurial nor Bazaar VCS are going anywhere anytime soon, either. – gotgenes Jan 21 '11 at 01:53
  • 4
    By the way, you're an awesome father getting your child started with revision control. I had to give a +1 just for that. :-D – gotgenes Jan 21 '11 at 01:55
  • 1
    Look at this way, bzr hosting is pretty well limited to canonical (though I'm sure there's *something* on savannah and maybe sourceforge). The bzr command is quite optimized for working with launchpad. For every bzr repo on launchpad, there are 76 git repos on github. Some people I respect really like bzr, but it's kind of a dead end. Many of the projects that do even visit bzr do so because canonical makes it the easiest way to get binary packages into Ubuntu as opposed to developers finding it to be the best tool for the job. (oh, and thanks! (: ) – Dustin Jan 21 '11 at 08:07
8

What you assumed to be one of Mercurial pros - revision numbering - is considered to be a disadvantage by many people. And what you assumed to be git disadvantage - staging area; being difficult concept - is considered to be advantage by many people.

So this is not that simple.

But if you ask me - Mercurial is James Bond, as one of the bloggers called it - it's elegant and higher-level than git, at least on the surface. Plus its commands are pretty much like subversion commands, therefore new users who are svn converts might learn Mercurial much faster than git.

Tomasz Zieliński
  • 16,136
  • 7
  • 59
  • 83
  • 5
    Revision numbering is a con because it's just not true. You can't refer to a revision by number outside of your own local repository at a particular point in time. If you're going to be cutting and pasting stuff to have a conversation about a change, you have to do it by hash or you'll end up talking about something else. – Dustin Jan 21 '11 at 01:17
  • @Dustin: Exactly, good that you mentioned it as it's not that obvious and my answer don't give a clue about this quirk. – Tomasz Zieliński Jan 21 '11 at 08:01
  • The staging area is defiantly an advantage of Git when you know how to use it, but at least I found it a bit confusing when I first tried Git (which was my first (d)vcs experience). Revision numbering being a disadvantage is a good point, but I still kind of like it :) – Paul Jan 21 '11 at 11:04
  • @Dustin protip: mercurial has hashes as well--it only exposes the decimal numbers in a local context. It's not hard to understand that decimal numbers are local addresses and hashes are global. On the other hand, just about everything about git is deceptive at worst or enigmatic at best. Here are 10 examples: http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ – weberc2 May 09 '14 at 18:54
6

I don't think your friends will notice a big difference with any of the three VCS. If it is just used as a simple backup with a small amount of branching (probably non-conflicting anyway), it doesn't matter which tool they choose. All three can do simple tasks without requiring the user to know any special stuff.

Especially if the people are completely new to version control, there is no real reason to choose one tool over the other. While all of them use slightly different concepts (with Git probably being the most special one), it is hardly something a new user will notice without experience with the other tools.

The distribution of your listed pros & cons (which are not really true btw) tells me that you have more or deeper experience with Mercurial than Git. As such I would recommend using Mercurial, because in the case where your friends need help, they can ask you, and you will be able to give them a good answer based on your own experience.

I think that is more important than the overall userbase in the Internet or on some help page (btw. the high amount of git questions could also mean that git is more confusing for many people – which probably is true to some amount).

Another factor on deciding on a tool for inexperienced users, especially when those might not really need it that much in their lives again, might be the availability of some easy graphical user interface. There might even be a good integration with their TeX editor, which would make them choose one tool over another.

poke
  • 369,085
  • 72
  • 557
  • 602
  • I actually have more experience with Git, but I've been playing with hg lately and enjoying it so the list might be a bit biased yes. TeX editor integration is a good point, but I don't think I've seen any with such capabilities for any vcs yet. – Paul Jan 21 '11 at 11:08
  • magit in emacs is really, really good. textmate was OK last time I tried (though magit is pretty far beyond anything I've seen) – Dustin Jan 21 '11 at 22:11
3

I'll pass on my experience with Git and Mercurial, in both cases starting from scratch.

I decided to move my team (5 top and disciplined developers, including myself) from ClearCase (UCM, but they'd all used both base ClearCase and UCM over several years). Having looked at all 3 of Mercurial, Git and Bazaar I settled on Mercurial (influenced heavily by PEP 374).

Within a week I felt confident enough to introduce Mercurial into the team processes and people started moving over to using it. The largest difficulty was making sure I'd be able to continue to push changes upstream to ClearCase. The whole team quickly adopted it and we noticed an immediate change in the way we worked.

We used very branchy development (named branch per task) - essentially inherited from how ClearCase worked, but we found it was a good way for the team to work (note - a lot of Hg users would not like this branching strategy). A developer would work on a task and send it to someone for review. Whereas previously the reviewer would go through and make notes, etc and send them back to the original developer, with Mercurial we found we would just switch branches, review, then get the author over and make the changes together in the reviewer's environment (pair programming) and commit them to the same named branch.

All up, total time for the entire team to get up to speed (with me as mentor starting from scratch) was about 2 weeks.

My experience with Git is more recent - I only started using it about 2 months ago (and so already had considerable experience with Mercurial). However, I did start using it about 2 months ago, and I'm only now starting to feel at all comfortable with it. The biggest thing that makes me uncomfortable with Git is that Git assumes you will be editing history and makes it easy. I have to regularly read parts of the git help/manual to check that I'm doing things "right". I find the local branch + remote-tracking branch system very foreign and unintuitive, whereas branching in Mercurial is incredibly simple (to find out where you are in comparison to another repo, you just ask it).

The team I'm working with is feeling the same way. Git was decided on for the VCS, but I've now been asked to change us over to Mercurial at the end of the current phase of work.

Tim Delaney
  • 5,535
  • 3
  • 24
  • 18
3

Recommend the one you know the best. If you're going to recommend one to your acquaintances, you should be willing to take first crack at answering their questions. Mercurial, Git, and Bazaar are all great, and vastly superior to nothing. If they ever find a deficiency, then they can try out one of the others, but honestly, for getting started, "Machts nichts!"

gotgenes
  • 38,661
  • 28
  • 100
  • 128
1

Git.

I happen to like Mercurial a lot and it was my introduction to DVCS but the reality is that Git is becoming the industry standard. When I talk to friends about what they are using at work, everyone is using Git for new projects, migrating existing projects to Git, or wishing they were able to use Git at work if they've used it for personal projects but can't get people to switch at work. Nobody talks about Mercurial or Bazaar, ever. I used to be the only person I knew who talked up Mercurial, but I jumped on the Git bandwagon as it became clear Git is what professional developers will be using for the foreseeable future. People still talk about SVN and very occasionally CVS, but that's because their projects started years ago and they haven't migrated yet, nobody talks about using them for new development.

If you guys plan to get jobs as developers after finishing your thesis, knowing the tools people actually use is in your best interest.

It's not one of your options but I just want to add that Perforce is terrible, should never have been developed, and is the most annoying and invasive VCS you can imagine.

Suboptimus
  • 309
  • 1
  • 6
1

I like Mercurial. I am biased. I also like Perforce, but it isn't as open.

jgritty
  • 11,660
  • 3
  • 38
  • 60
1

The tags on StackOverflow should give you a pretty good indication of the community support behind it. Currently the counts of questions are:

  • Git: 5,789
  • Mercurial: 1,845
  • Bazaar: 188

Demonstrating this in pie chart form:

I LIKE PIE (charts)

Now, this shouldn't be taken as a sign that Git is more difficult to use than Mercurial, but rather that there's a lot of people asking questions about it and receiving help about. This means that if your newbies got stuck they'd have a greater chance of receiving help in the git tag than in the Bazaar tag.

I cover some of the basic git commits in my answer to "Should a developer always use version control".

Additionally, there's GitHub which is a really awesome git repository hosting site that, much like a good Red, gets exceptionally better with age. Their new file browser, for example, had me nerdgasm'ing.

In summary, I definitely think the newbies should use Git because there's a larger community of people out there using it, GitHub uses it and if they happen to use the Ruby programming language, it's effectively the de facto standard there.

Community
  • 1
  • 1
Ryan Bigg
  • 106,965
  • 23
  • 235
  • 261
  • 9
    I would caution against arguing the number of questions on Stack Overflow correlates with amount of community support. As [poke points out](http://stackoverflow.com/questions/4753684/git-hg-or-bzr-what-to-recomend-to-a-new-user/4754239#4754239), the number of questions may be proportional to the complexity of the tool. Quite honestly, I think they all have a sufficiently large enough community to get support. – gotgenes Jan 21 '11 at 01:44
  • 2
    @gotgenes: I don't think that's the case at all. Git has the biggest community on Stack Overflow and there's a ton of people who use it (the Ruby community, for one). If there's a large number of questions, then the common stumbling blocks will be covered by them, thereby making it *easier* to use. – Ryan Bigg Jan 21 '11 at 02:00
  • 2
    SVN has over 7000 SO questions. Judging from [poll results](http://stackoverflow.com/questions/782375/which-is-more-popular-currently-by-recent-install-base-svn-or-cvs/783548#783548) it is also used more than git out there in the real world. – Wim Coenen Jan 21 '11 at 10:36
  • @Wim: SVN was the next best (free) thing to CVS for a very long time and there has been a high level of adoption for it over the years it has been around. Git, in comparison, is fairly new. When I said "Git has the biggest community", I should have said "biggest DVCS community". – Ryan Bigg Jan 21 '11 at 11:02
  • 2
    @Ryan You're still making (admittedly plausibly valid) assumptions: the number of stumbling blocks is equal, the quality of the questions is equal, that SO hosts equal proportions of support-oriented interactions for each tool, etc., to state that quantity equals coverage. I'm not saying your points are invalid, I'm saying, recognize the caveats. In any case, I stand by my statement that there is sufficient support for any of the tools. – gotgenes Jan 21 '11 at 16:03
  • This isn't exactly scientific... but I learned to use hg first, then git. I visited SO for hg questions perhaps 3 or 4 times... several dozen for git. With that said, I don't really doubt those numbers either. – jkerian Jan 22 '11 at 06:03
  • Disagree with the overall hate level for this answer. This is an interesting data point and while it's not conclusive, arguing that a high level of interest actually means it sucks is a pretty weak counter. Like it or not, learning tools other people use is valuable if you actually need a job doing this stuff, whether those tools are theoretically optimal or not. If you're out there talking to other developers about what they're doing you know they are all talking about Git when they talk about version control. – Suboptimus Jun 13 '12 at 05:28
  • I'm _sure_ the SO proportion is a composite of popularity _and_ complexity, despite your baseless objections. I have comparable experience with git and hg and git is infinitely more complicated in my experience. It's practically impossible to prove objectively, but I have an extremely hard time believing any honest person could definitively say git is simpler/easier than hg or bzr, and I have comparable experience with git and hg (and very little with bzr). – weberc2 May 09 '14 at 19:00