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
  • 21,442
  • 29
  • 112
  • 288
Gregory Eric Sanderson
  • 279
  • 2
  • 5
  • 2
    git has a lot of power enabled by default, but everyone I've talked to say mercurial is simpler to learn, and I am inclined to agree based on my experiences using both. And yes, the mercurial tools are easier to install in Windows vs. their git equivalents. That said, expect to guide people and point them at tutorials for the first week (or more...). – wkl Oct 28 '11 at 20:34
  • Indeed, I expect a lot of questions in the beginning but that's ok since it's a normal part of learning something new. I just don't want the DVCS becomming a hinderance to productivity and having to debug a problem every day – Gregory Eric Sanderson Oct 28 '11 at 21:02
  • 1
    Using a DVCS from the beggining is likely to be the simplest way to manage merging contributions from multiple contributors working in parallel. If you find anonymous heads confusing, don't use them (mercurial supports named branches). – Stephen C. Steel Oct 28 '11 at 21:20
  • IDE support or CLI? –  Oct 28 '11 at 21:26
  • 2
    Time again to link to this blog post? [Git is a Harrier Jump Jet](http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump-jet-and-not-in-a-good-way/). – sbi Oct 28 '11 at 21:32
  • IDE support would be nice but isn't necessary. I don't mind using the CLI, but I don't think the other students would – Gregory Eric Sanderson Oct 28 '11 at 21:39
  • @sbi that post looks more like a rant than a constructive argument as to why I should not choose git. Personally I prefer git over mercurial, but since i'm working with people who are new to DVCS i'm considering both. – Gregory Eric Sanderson Oct 28 '11 at 21:49
  • @Gregory: "Well, one thing that's wrong with git is that it's not just [internals leaking through some abstraction](http://www.joelonsoftware.com/articles/LeakyAbstractions.html), staining the floor with a few wet spots, but rather that it's a whole ocean of internals you have to cross on your own, with treacherous maelstroms, and all you have as abstraction to get you to the other side is a rotten door to sit on and a wooden spoon to paddle with." - ([Me the chat](http://chat.stackoverflow.com/transcript/10?m=1753626#1753626) the other day.) – sbi Oct 28 '11 at 22:12
  • 1
    I never understood why the whole "too hard to learn" matters. Okay, so it takes 20 minutes to learn how to commit and branch and such as opposed to 10... Big deal? – alternative Oct 31 '11 at 20:38
  • 1
    Watch (one of) them go through http://hginit.com/ and take actions based on their reactions. – chelmertz Nov 04 '11 at 21:27

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,644
  • 1
  • 18
  • 25
Rook
  • 19,861
  • 9
  • 53
  • 96
  • 4
    + for "VCS is a tool". I hadn't considered the "small things" as a factor, but it's true that when you add up small problems here and there they can become a real nuisance. – Gregory Eric Sanderson Oct 28 '11 at 21:53
  • 8
    "Version control system should not be something one spends time learning." This is a load of crap. You should always spend time learning your tools. You spend time learning your compiler; but the VCS is just as critical a tool for your programming as your compiler is. – JesperE Oct 29 '11 at 07:31
  • 9
    +1. Especially the 'second class citizen on windows' argument is absolutely important in this situation. – tdammers Oct 29 '11 at 08:23
  • +1 for "WTF(s)/minute" (http://www.osnews.com/story/19266/WTFs_m). These kids gotta learn the skillz :-) – Ross Patterson Oct 31 '11 at 10:50
  • IMHO Mercurial branches are ***more* powerful** and flexible than `git` branches. Named branches are a significant advantage for some workflows, bookmarks allow you to replicate `git` workflows and automatic creation of topological (anonymous) heads means you never *have* to explicitly name branches if you don't want to. – Mark Booth Oct 31 '11 at 17:16
  • 1
    @Mark that's just a result of a terminology difference... A branch in Git is really just a name. – alternative Oct 31 '11 at 20:43
  • @mathepic - A git branch is a named reference, a pointer into the revision graph, like an `hg` bookmark. At any point that pointer can be deleted or pointed elsewhere. In `hg` a *named branch* is baked into the immutable history of a commit, so it is a very different entity, and very useful for some workflows which don't rely on constant rebases. – Mark Booth Nov 01 '11 at 12:07
  • +1 Even though I disagree (well written answer!). Git is superior. – Jess Telford Nov 12 '11 at 06:24
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
  • 10
  • 12
  • Being a "console junkie" myself i've never used the Tortoise{Svn,Git,Hg} apps before so I didn't know TortoiseHg had a branch graph. I'll have to go check that out – Gregory Eric Sanderson Oct 28 '11 at 21:27
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,608
  • 3
  • 71
  • 142
Spencer Rathbun
  • 3,576
  • 1
  • 21
  • 28
  • I've heard good things about fossil, but unfortunately I don't have that much time to get familiar with a new DVCS. I prefer using something i'm used to (if possible) since I already know how to work around the most common pitfalls. But thanks for the suggestion, I'll definitely look into it once I have the time. – Gregory Eric Sanderson Oct 28 '11 at 21:22
  • +1; fossil is little known but it's so easy to work and so self-contained (dvsc+wiki+tickets+webserver) that it _is_ a real alternative to the whole of trac or even github. – Javier Oct 29 '11 at 21:02
  • But fossil will not look as good on the students CV as git or hg, as very few poeple have hard of it. – Ian Nov 01 '11 at 12:38
  • Mercurial has built in hg serve functionality too. It misses a bug tracker and wiki of course. But then theres also bitbucket.com – Johannes Rudolph Nov 19 '11 at 21:49
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
  • 352
  • 1
  • 7
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,287
  • 2
  • 34
  • 45
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,214
  • 3
  • 40
  • 79
  • You don't have to delete the git branch after you are done; it is only custom. Also -1 for misinterpreting uses of the index - you don't use it for staging bad commits, you use it for staging _partial steps_ of a larger series of commits. Usually this happens during a rebase when you are clearing up your history. – alternative Oct 31 '11 at 20:45
  • @mathepic - If you don't delete branch names, and push all of your local 'fix' branches up to remote then you are going to end up with a huge number of refs, just like you end up with a plethora of old branches in svn. In `hg` these branch names are always topologically local, so you only see them if you look for them. – Mark Booth Nov 01 '11 at 12:03
  • @mathepic - As for your -1, I think you are misinterpreting what I'm saying. I can't imagine why anyone would intentionally make a bad commit, but with git it is easy to do it by accident. If you forget that file `c` implements a modified interface in file `i` and accidentally commit the `i` without `c` then if someone pulls in your changes before you've got around to committing `c` their compile will fail. If you use the stash/compile/commit workflow instead, this mistake is simply not going to happen as your own build will break first. I've tried to make my answer clearer though. – Mark Booth Nov 01 '11 at 12:04