In short, what are the advantages of git and mercurial over subversion?

Question

Hi,

Can someone tell me what the hype is over Git and Mercurial over Subversion?

Answer 1

Git and Mercurial are distributed, SVN is not.

Advantage or not? You decide...

Answer 2

A pro-git comparison to various source control systems can be found at http://whygitisbetterthanx.com/ . What I most like about git is:

• Its faster.
• It doesn't duplicate source code like SVN does in .svn subdirectory.
• It allows committing offline then pushing.

Answer 3

This isn't so much that one side it "better" than the other, it's that GIT, Mercurial, et al allow you to work in ways that are different from Subversion or CVS. Subversion and CVS offer only a centralized repository structure, while the others are "distributed." The distributed approach makes it easier to to ad hoc collaboration between developers, and may also affect how you manage groups of changes on your own computer.

Which method fits best for you is something you or your organization will need to decide.

Answer 4

For me one important thing: SVN doesn't really support tags:

1. Tags are not symbolic. They are paths in repo (COW copies)
2. In SVN a file belongs to a tag (because tag is a copy of file). In other systems and in human intuition: tag belongs to a file. It's oposite relation.
3. Therefore it is hard to list something like: "all tags the files has". This information just isn't stored directly in SVN repository.

Answer 5

As far as Git goes, I think there are quite a few, the biggest of which (in my opinion) is Git's advanced branching and merging support. Git makes it really, really easy to branch, and its ability to merge in changes is much, much better than that of SVN's. Tools like gitk also make it really, really easy to visualize the relationships between branches in a Git repository.

There are numerous other benefits. I think Git has better tools and a better toolchain, and the fact that it doesn't require a central repo and a "checked out" repo is nice when you're working on small projects by yourself. I think merging and branching is the biggest benefit, though.

(A lot of that goes for Mercurial, as well, although I never liked Mercurial's emphasis on local clones for "branching"; I much prefer Git's method of keeping all the branches in the same repo.)

Answer 6

You have the same range of "differences" between Git and SVN than between Git and CleaCase
(see my post on those "VCS core concepts")

• SVN: linear central VCS, where branch and tag are the same (a point in a linear history).
• Git: DAG (Directed Acyclic Graph) distributed VCS, where every path of the graph is a branch, and every workspace is the full repository.

Since Git is content-oriented, it will merge much more efficiently than Subversion by:

• finding very quickly within its graph what need to be merged
• applying the right patch

Answer 7

For me, svn is working fine. For 1 - 10 developers, based on experience.

It is clear where the 'real' version lies - out in the cloud on the redundant host (hopefully some place that looks after your data and uptime). It looks like reading about git is that it is more complicated, bigger and more capable. So if you want an 'svn centralized' workflow, (see the http://whygitisbetterthanx.com/ site) with fewer ways to do things, etc, then use svn.

I used CVS until it was obvious where all the fun was. I guess in a few years, if I change again, it will be to git? But really - if you are spending time with your version control system on any day other than the day you set it up, then you are doing something wrong.

Answer 8

Say you have a personal project, would you put it under version control? (I hope you say yes).

If so, then, wouldn't you rather something simple? Git doesn't require you to setup a server or anything like that. Your working directory is your repository.

Wanna try some new crazy idea? Just branch and experiment with it in that branch. If it's successful, go back to your main branch and merge. If your idea didn't work out very well, just go back to the main branch and delete that crazy_idea branch.

Wanna work on a crazy_idea but also continue to develop the master branch normally? Again, no problem, you can switch back and forth between branches, and only merge crazy_idea after it's matured enough.

Even if you're in a team, each developer (or a small group of developers) can work on some idea in an experimental branch before merging it in with the rest of the code.

I suppose it makes open source even easier. You don't need to give access permissions to anyone. If someone has implemented a great feature, he can request you to pull from him. If you like what you see, you can merge it.

Here's a surprise: git is much much simpler than svn.

Really. I always heard of version control, but never did it. The time I tried to put my code under a local svn server, it was a nightmare; I really hated it.

Now, I put everything under git.

Answer 9

They conceptually organize revisions as changesets which allow you to very easily branch/merge your code. Merging a branch in SVN is an excruciatingly painful experience.