26

A bit of context: I'm in 3rd year of college. students are divided into teams of 4. Almost everyone will be working under windows (except a few like me who are on linux). As part of the school curriculum, we will soon start working on a project for a real client, but me and another team are wondering which way would be best for sharing our code with each other.

I've been working part-time for 3 years and have had plenty of experience using both git and mercurial on different projects, so I don't have any problems using one system or the other. However, none of my teammates have ever used a version control system before. There's also another team who've tried using SVN but have had major problems and would prefer trying out something else, so they've asked for my opinion.

My thoughts : I've heard that mercurial + TortoiseHg has a better integration under windows, but I'm wondering if the concept of anonymous heads might confuse them even If I explain them. On the other hand, I find that git branches are easier for a beginner to understand (clear seperation of work for each programmer) but doesn't work as well under windows.

gnat
  • 20,543
  • 29
  • 115
  • 306
Gregory Eric Sanderson
  • 279
  • 2
  • 5

6 Answers6

49

Mercurial, without a doubt.

This is of course, subjective, and vaires from one person to another, but the general opinion is that Mercurial is easier to grok, expecially to someone new to VCS or someone coming from one of the old generation VCS's.

Points in hand:

  1. Mercurial was developed with Windows in mind; Git was ported. No matter what anyone tried to tell me, Git is still a second rate citizen on Windows. Things have certanly improved over the past few years, but you still see a lot of bickering of why something works/or doesn't work on Windows as it did on *nix box. TortoiseHg works very nicely, and Visual Studio implementations are even easier to use without breaking your workflow.

  2. If someone starts the discussion "Git is more powerful after you ...", then he's pretty much saying it all. For 95% of users Mercurial seems more intuitive. Starting from a lack of index, to its more intuitive options (option switches are coherent), to its local numbers for commits instead of SHA1 hashes (who ever thought SHA1 hashes are user friendly??!)

  3. Mercurial's branches are no less powerful than Git's. Post describing some of the differences. Going back to some previous revision is as simple as "update old-revision". Starting from there; just do a new commit. Named branches are also available if one wishes to use them.

Now, I know that all these are details, and they can be learned and everything, but the thing is ... these things add up. And in the end, one seems simpler and more intuitive than another. And version control system should not be something one spends time learning - you're there to learn programming and then to programm; VCS is a tool.

Just to note; I use Git and Mercurial daily. Don't have trouble using either one of them. But when someone asks me for a recommendation, I always recommend Mercurial. Still remember, when it first came into my hands, it felt very intuitive. In my experience, Mercurial just produces less WTF/minute than Git.

eykanal
  • 1,684
Rook
  • 19,947
10

I've found that the TortoiseHg UI is a great experience on Windows. When experimenting with Git in the past, I ended up going to the command line instead. To your average user, a good UI is much more approachable than a command line. So, I'd suggest using Mercurial. (It includes a nice branch graph in the workbench window, too. It should clear up any of the basic branching difficulties.)

Once they understand things from the UI perspective, they may end up going to the command line to script or do manual operations - but they don't need to.

John Fisher
  • 1,795
4

If you're interested in a third option, I'd suggest fossil. I find the ability to throw up a temp web server to share code works great in small projects. Fossil is just an executable, so you could put it and your source into a thumb drive, and use it from any university computer.

Use fossil ui to start a temp web server wherever you are to have your fellow students sync up with you. It also gives you a ticket system, wiki, and easy to use web interface for changing branches and tagging commits.

Just make sure they read the quickstart guide, and/or the book. Finally, there is a project called winFossil to give them a friendlier user interface than the web ui.

kevin cline
  • 33,798
Spencer Rathbun
  • 3,576
3

Given that the teams are new to version control, and many are using Windows, I'd recommend mercurial over git.

The conceptual model of version control used by git and mercurial are very similar, so once you've mastered one, it's easy to pick up the other (and for similar reasons, it is quite easy to convert a repository from one to the other). This means its not a big deal if you change your mind later.

In my opinion, mercurial is easier for new users to learn. It makes simple things easy, and dangerous ones hard. Git makes dangerous operations easy (easy to do, not necessarily easy to do correctly!).

The TortoiseHg interface for Winodows is very nice too, and is another argument in favour of using mercurial.

Stephen C. Steel
  • 392
2

My personal preference is for git.

However, as some people will be using windows and the superb hginit tutorial exists, I'd recommend teaching them mercurial.

dan_waterworth
  • 7,327
0

As many people have suggested, Mercurial via TortoiseHg has a very low barrier to entry.

For those on Windows it's a single installer rather than two installers (and a whole load of stuff they might not want to learn about) and the THg user interface is much more polished than TortoiseGit+Msysgit.

Anonymous heads

If you think they would be confused by anonymous heads, then don't encourage their use. Most hg books take a balanced approach and teach both topological and named branches, and let the reader determine which is most appropriate for their use.

Named branches

One thing I really miss in git is hg's named branches, so that's one option. git branches are fine while you are working on them, but once you've merged that work into another branch, you lose much of the context for those changes.

In hg you could create a branch called Jira#1234 and always be able to find all of the revisions associated with that fix. In git, once your branch is merged in and the ref deleted, you have to infer which revisions were part of the fix from the topology of the revision tree. Even if you don't delete the ref, you still only know the last commit on that branch, not which of it's ancestors were part of that chain of commits.

Bookmarks

Alternatively, if you don't want to use named branches, but want a git style workflow with your anonymous branches, then you can use bookmarks instead.

This could be the best of both worlds - they get to learn a git workflow, but get to use the simpler hg commands.

Index/Cache/Staging area

Personally, I think students are far more likely to be confused by the git's index/cache/staging area than by hg's anonymous heads. I much prefer hg making this advanced functionality optional on the command line, over the way git assumes you always want/need to use it.

I also think that the staging area encourages commits which haven't been tested or even compiled. Since many of the places I've worked have had a don't commit if it doesn't compile rule, I would much rather shelve/stash changes I don't want right now, re-run unit tests and commit a version that I know compiles.

When you later come to track down a bug using hg bisect or git bisect, you will thank yourself that you can test all of the revisions, not just the ones that compile.

Mark Booth
  • 14,352