mercurial vs. svn (or tfs)

[Justin Collum]

Troy:

(at least I think it was Troy that talked about this)

Would you mind posting a summary of your decision to go with Mercurial
over SVN (or TFS)? It sounded like you looked at the change with a
critical eye. I know someone who might benefit from your opinion.
Specifically:

-- why not stick with SVN?
-- why not go with TFS instead?
-- how difficult was the transition?

[Troy Howard]

And I almost forgot one important point... 

I can continue working in a disconnected scenario.. with version control the whole time. So like.. that 4 hour plane ride.. I can code on my laptop and commit every hour, then sync up when I get to an internet connection. 

I can ALSO review the entire history of the repository while on the plane, disconnected form my server, because it's all in that .hg folder. Pretty handy. 

It means I could, in theory, stick my codebase on a thumbdrive, go home, work on it there for a while (without VPNing in to my office), then bring it back in the morning, and check it in. 

You could do the same with SVN, but you couldn't see history or track revisions during your disconnected time..

Thanks,
Troy

On Thu, May 27, 2010 at 5:21 PM, Troy Howard <thow...@gmail.com> wrote:

This is also a great read:

Subversion Re-education

http://hginit.com/00.html

On Thu, May 27, 2010 at 5:15 PM, Troy Howard <thow...@gmail.com> wrote:

Justin, 

No problem... Love to talk about it. 

Some of the points I considered when choosing wether or not to switch were: 

• Single Version of the Truth - One of the great things about CVS is having a server to go to to get the "official" latest version. DVCS seems like you lose that, initially, until you realize that you can still have a server, which has an official version, just like with CVS, but you don't *need* to have it. 
• Backup Concerns - How to ensure that all versions are backed up? Well, two-fold answer.. Just like with CVS, you can have a backup policy on your centralized server, which backs up that version. Just like with CVS, you won't get backups of people's local changes on their workstations that haven't been committed to the centralized repo. However, the plus side for DVCS is that each local working copy is a full backup. That's pretty good coverage...
• Merge Conflicts - It just works.. better or equivalent to SVN. Good enough for me.
• Encourages Smaller Commits - Since you can commit locally and push to the centralized server only when you're ready, it prevent the "big infrequent commit" syndrome. That's where a dev makes a bunch of changes locally, and doesn't commit them for fear of breaking the build, or disrupting other dev's processes. This can represent days, weeks, or in some cases months of work that isn't being version controlled. The CVS way of dealing with this is via branches.. but those litter up your repository, and often don't merge well. With Mercurial this all happens locally, and you can even share your "local branch" with other people merging between thier local branch and yours, all without touching the "central server". This is a great workflow, and encourages branching, specifically, branching the right way. 
• Tooling - I like the tooling surrounding SVN. TortoiseSVN, Ankh, and VisualSVN makes life a lot easier. A big selling point for Mercurial is that there is already TortoiseHg and VisualHg, which are nearly identical to their SVN counterparts. This makes it really easy to switch over.
• Adoption on OSS Collaboration Sites/Tools - Google code offers Mercurial, Codeplex offers Mercurial, SourceForge offers Mercurial, Redmine supports Mercurial... They must be doing something right to be so widely adopted so fast. 
• Can Import your SVN Repo, With Full History! - This is a big selling point. I can move from SVN to Mercurial and not lose my revision history. Score.
• Don't Fix It If It Ain't Broke - SVN works fine for us. We don't actually *need* to change to Mercurial. But it's really better in a number of substantial ways, not the least of which are ease of merges, and encouraging more frequent commits and more branching. 
• Mercurial is SVN 2.0 (IMO) - This is how I think of it. By switching to Mercurial, I'm just upgrading my SVN installation to the latest version. Obviously, they are not the same codebase, but they are very similar tools that solve the same problem. Mercurial solves it better. I'm upgrading my SCM, I don't care what name it has, just that the new version works better, solves more problems, and doesn't present any new bugs or issues that will screw me up. Mercurial fits that description.

So, in a nut shell -- Mercurial can do everything SVN can do, and more. It's an easy migration, and only results in a net benefit. Not to mention it means that me and my dev staff get to learn and play with something new and interesting that the development community at large is excited about. That's a big plus. We love to do that. If that was the only reason for considering Mercurial, I wouldn't bother, but it's a nice last reason... Icing on the cake, if you will. 

I think Joel Spolsky give a much better explanation of the fundamental reasons why its better.. Here's a quote:

"With distributed version control, merges are easy and work fine. So you can actually have a stable branch and a development branch, or create long-lived branches for your QA team where they test things before deployment, or you can create short-lived branches to try out new ideas and see how they work.

This is too important to miss out on. This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.

Or, to put it another way, I’d go back to C++ before I gave up on Mercurial.

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now." 

- Joel Spolsky, Distributed Version Control is here to stay, baby [link]

With regards to TFS, I've never seriously considered using it. Prior to Mercurial, SVN was the only reasonable SCM system. Prior to SVN we used Vault, which wasn't terrible, but not as good as SVN. 

TFS is simply not how we work, or want to work. Our world view is not that narrow.

The transition itself has been painless -- though we aren't fully moved over yet. That's mostly because we haven't had much time for administrative and maintenance tasks recently due to work load. We'll probably complete the process within the next month. I don't foresee any issues with that, as what we've already moved over has worked out really well.

Hope that helps.

Thanks,
Troy

[Troy Howard]

[Troy Howard]

[Justin Collum]

Thanks Troy. Thorough and informative as always.

I'm curious about one bit: "Our world view is not that narrow."
Elaborate?

On May 27, 5:15 pm, Troy Howard <thowar...@gmail.com> wrote:
> Justin,
>
> No problem... Love to talk about it.
>
> Some of the points I considered when choosing wether or not to switch were:
>

>    - *Single Version of the Truth* - One of the great things about CVS is

>    having a server to go to to get the "official" latest version. DVCS seems
>    like you lose that, initially, until you realize that you can still have a
>    server, which has an official version, just like with CVS, but you don't
>    *need* to have it.

>    - *Backup Concerns *- How to ensure that all versions are backed up?

>    Well, two-fold answer.. Just like with CVS, you can have a backup policy on
>    your centralized server, which backs up that version. Just like with CVS,
>    you won't get backups of people's local changes on their workstations that
>    haven't been committed to the centralized repo. However, the plus side for
>    DVCS is that each local working copy is a full backup. That's pretty good
>    coverage...

>    - *Merge Conflicts* - It just works.. better or equivalent to SVN. Good
>    enough for me.
>    - *Encourages Smaller Commits* - Since you can commit locally and push to

>    the centralized server only when you're ready, it prevent the "big
>    infrequent commit" syndrome. That's where a dev makes a bunch of changes
>    locally, and doesn't commit them for fear of breaking the build, or
>    disrupting other dev's processes. This can represent days, weeks, or in some
>    cases months of work that isn't being version controlled. The CVS way of
>    dealing with this is via branches.. but those litter up your repository, and
>    often don't merge well. With Mercurial this all happens locally, and you can
>    even share your "local branch" with other people merging between thier local
>    branch and yours, all without touching the "central server". This is a great
>    workflow, and encourages branching, specifically, branching the right way.

>    - *Tooling *- I like the tooling surrounding SVN. TortoiseSVN, Ankh, and

>    VisualSVN makes life a lot easier. A big selling point for Mercurial is that
>    there is already TortoiseHg and VisualHg, which are nearly identical to
>    their SVN counterparts. This makes it really easy to switch over.

>    - *Adoption on OSS Collaboration Sites/Tools* - Google code offers

>    Mercurial, Codeplex offers Mercurial, SourceForge offers Mercurial, Redmine
>    supports Mercurial... They must be doing something right to be so widely
>    adopted so fast.

>    - *Can Import your SVN Repo, With Full History!* - This is a big selling

>    point. I can move from SVN to Mercurial and not lose my revision history.
>    Score.

>    - *Don't Fix It If It Ain't Broke* - SVN works fine for us. We don't

>    actually *need* to change to Mercurial. But it's really better in a number
>    of substantial ways, not the least of which are ease of merges, and
>    encouraging more frequent commits and more branching.

>    - *Mercurial is SVN 2.0 (IMO)* - This is how I think of it. By switching

> > - Joel Spolsky, Distributed Version Control is here to stay, baby [link<http://www.joelonsoftware.com/items/2010/03/17.html>
> > ]

>
> With regards to TFS, I've never seriously considered using it. Prior to
> Mercurial, SVN was the only reasonable SCM system. Prior to SVN we used
> Vault, which wasn't terrible, but not as good as SVN.
>
> TFS is simply not how we work, or want to work. Our world view is not that
> narrow.
>
> The transition itself has been painless -- though we aren't fully moved over
> yet. That's mostly because we haven't had much time for administrative and
> maintenance tasks recently due to work load. We'll probably complete the
> process within the next month. I don't foresee any issues with that, as what
> we've already moved over has worked out really well.
>
> Hope that helps.
>
> Thanks,
> Troy
>

[Jayson Barley]

I wanted to thank you guys for the presentation that you did. I have actually been using Mercurial on my personal projects and for local commits before pushing back to our central repository. I just added a pre-build event in Visual Studio to perform a commit each time I build. When I add a test and run them in VS, it does a commit and then builds. This allows me to to go back and follow my workflow as I created tests and modified the source code to make those tests pass.

Jayson

[Justin Collum]

Wouldn't you want that to be a post build event? Are you committing
possibly-builds code to your repository?

Damn good idea though. What's the central repository in this case?

[Eric Williams]

Troy - how are you sharing your Hg repos?  Publishing over HTTP, SSH or just a network (unc) share?  Also how are you dealing with access controls if any?  Dev A can push to Repo1 but not Repo2 etc.  I've been looking into IIS setups but with the CGI / Python goo it's no surprise that Kiln & Bitbucket exists as products.

As an aside, I was chatting with Andy Sherwood this afternoon and he pointed me to the HgSubversion [1] project for using a Hg client with a SVN 'server' for those folks that are in that type of a setup.  Neat stuff...

-Eric

[1] - http://mercurial.selenic.com/wiki/HgSubversion

[Troy Howard]

I was being a bit flippant, but what I mean is that we use a variety
of tools here, not just MS tools. We have code in numerous languages,
and people working in Linux, Mac, etc.

TFS is very MS focused, and you really get the most bang for your buck
out of it when you can integrate it with other MS tooling like
Sharepoint, Visual Studio, etc... We're trying to move as much stuff
into the OSS stack as possible to ease virtualization, keep costs
down, and simplify maintenance. We don't really have much in the way
of MS products other than VS, Office, and and Windows.

I did install/play with it, research it somewhat, and talk to others
who use it... but as I said, never really seriously considered it. For
that reason, my opinion may not be fully informed.

If I were someone, reading this commentary, trying to make a decision
regarding TFS, I'd listen to the opinions of people with more
practical experience with TFS than I have.

Thanks,
Troy

[Troy Howard]

Right now it's a UNC share, but I'm planning to move to HTTP
publishing using Nginx on a Ubuntu box.

I wouldn't suggest setting it up under IIS. If I was going to do HTTP
serving on a Windows box, I'd install Apache and set it up that way.

Since we're doing UNC access control is file system based. When moving
to HTTP there's a few options.. Could do authentication on the web
server, and link to LDAP/Active Directory or something of that nature,
or could use built-in authentication in the .hgrc...
It mostly depends on how much I feel like fiddling with it at the time. ;)

Using hgrc auth is the path of least fiddling, but it means that I'll
have to duplicate maintenance work when administering the accounts. If
I can tie into our AD user control, then it's a single point of ACL
control, which is nice.

That said, we're pretty easy going about that around here. Our
collaboration servers are not internet facing, and all developers have
equivalent access to our systems.

Thanks,
Troy

[Jayson Barley]

TFS is the central repository. I am committing code that may not build but the number of times that actually happens is very rare.