views:

769

answers:

7

The team I'm working with uses SVN for keeping version control. (It was used for years by them.) Recently I found Mercurial as a VCS and it looks much convenient for me than SVN.

What arguments wound you suggest most convincing in order to move to Mercurial?

+25  A: 

There's Joel Spolsky's introduction to HG, hginit.com.

Mercurial is a modern, open source, distributed version control system, and a compelling upgrade from older systems like Subversion. In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts.

The first chapter is named

Subversion Re-education

He makes a good case, I use Subversion and am very tempted to switch.

Pekka
Well, I read Joel's introduction and it is really good, but I need to perform some initial convincing so they want to read it too
Regent
That chapter works really well for other DVCS:s as well. Just s/hg/git/ for example. :)
calmh
hginit.com has a nice intro to mercurial. but the first svn bashing chapter is full of crap. my code isn't perfect, yet it doesn't "cause trauma to the whole team" because we know how to apply feature branches. and we know how to use them without needing "six programmers for two weeks" to reintegrate it into trunk. this has never taken longer than a few minutes. and here's one last one that i like a lot - joel: "Now, here’s how Subversion works: When you check new code in, everybody else gets it." - well that says about all, it's BS like the rest of the first chapter.
stmax
@stmax thanks for adding this, interesting. I don't know enough about feature branches on that level, and I like HG's approach to the issue better nevertheless. Still, your comment is well noted.
Pekka
+4  A: 

Your team either works on a project complex enough to warramt mercurial or it doesn't .... if it does -- you should have felt the chaffing long ago, and so would everyone on your team.

Hassan Syed
But are there any advantages in using Mercurial with not very large projects?
Regent
There are, and I agree with all of them. However, currently the whole world is using SVN :D Take it easy, get together a few fellow developers and start playing with mercurial (read: not git), it will eventually catch on :D you can run mercurial and SVN at the same time (with a bit of convention)
Hassan Syed
+3  A: 

Spell it out to them in their terms. Why would it be better for them, what problems which they currently encounter would be solved by it. Not, on the other hand, what Mercurial does that is better than Subversion. E.g. if it supports distributed repositories yet your organisation has no need for them, then I wouldn't be focusing my pitch on that particular aspect. This is something we can't tell you as we don't know how your organisation works.

You should also consider integration with existing tools, i.e. will it work in the IDEs you use, with the same or better level of usability?

Mike
We primarily use VS2008 for our development and fortunately there is a great plug-in for it -- http://www.newsupaplex.pp.ru/hgscc_news_eng.html
Regent
+8  A: 

Are you looking at disadvantages of Mercurial over SVN too? A professional unbiased evaluation needs to analyse disadvantages too.

For me, I think the main ones are:

  • Mercurial doesn't handle Unicode filenames out-of-the-box on Windows (you need an add-on module FixUtf8Extension). Subversion's Unicode support seems quite mature.
  • A weakness of all DVCS is that their distributed nature doesn't work well with non-mergeable files (many proprietary or non-text document formats). For my company, we store just about everything in Subversion, including many design docs in Word, Visio, etc. A centralised VCS handles non-mergeable files by letting you lock the file before editing.
Craig McQueen
Lack of proper Unicode support is the main thing I don't like in Mercurial at the moment -- FixUtf8Extension doesn't work on my box for some reason. As for non-mergeable files -- for documents we use a another control system which supports aprroval workflows and other stuff useful for documents.
Regent
Some other issues to think about: svn:externals and repository structure. Hg does not have an svn:externals equivalent. Also, Hg does not handle the "all your projects in 1 big repository" model. If you dev team makes extensive use of those features, you're going to have a hard time switching.
msemack
@msemack: An `svn:externals`-like feature is provided by the 3rd-party extension [HgExternals](http://mercurial.selenic.com/wiki/HgExternals). I haven't tried it myself.
Craig McQueen
@msemack: You're making a good point here. As far as I know hg does not allow working on subtrees (of one big repository) - this is something that did come in really handy with SVN...
fmuecke
+6  A: 

Keep in mind when you are trying to convert them to use hg that some of them would rather kill several members of their family than take 5 minutes to learn a new piece of software.

With this in mind, If you can successfully convert the repository to hg on your machine than you might be able to show them the benefits.

Show them how commiting doesn't mean screwing everyone else. Commiting means 'let me track what I am doing'. Show them how cloning is so fast, and you can have an instant sandbox for new ideas.

Show them that merge actually works.

I say good luck. It is a huge uphill battle to convince people to change their workflow.

mfperzel
+9  A: 

If you don't have compelling arguments yourself, then you should ask yourself why you really want to switch.

If however you know yourself what's better in hg than in svn, what feature you would benefit from that hg has and svn doesn't, then you also have your arguments to convince your team and you don't have to ask here.

Just switching because something seems to be cooler without even knowing why is always a bad (ok, very bad) idea.

Stefan
A: 

Assuming your primary reason for switching is likely because Mercurial is a distributed version control system, keep in mind the DVCS functionality is coming to SVN in 1.7 which is due somewhere around the middle of the year: http://subversion.wandisco.com/component/content/article/1/44.html

Troy Hunt