Mercurial (Hg for short, as it is the symbol for Mercury) is a Distributed Version Control. Much like GIT, although much simpler.

TFS has its legacy in the thinking that SourceControl should be centrally locked down. That makes sense in a cleanroom scenaro. But the moment one adds USBs, VPN, and the ability for remote users to clone whole trunks to their home desktop, one has lost any pretense at secured access.

Another problem with the central repository model, is around authentication/authorisation. TFS is tightly integrated with AD, this can cause a lot of unresolvable problems for enterprises that want to outsource all or parts of the development process: either remote parties have to VPN in to dev, or trus relationships have to be set up between two AD environments. Not going to happen for many places (banks, etc.)

The solution that Linus and others came up with was a distributed source control system, where everybody works in self contained repositories that contain everything. At first, that sounds nuts in terms of security – but it actually turns out to be a positive manouver. THe more poeple who can view code, the stronger it gets.

For intellectual IP, it's a different story. That has to not get out. And the only way to do that is with secured environment, with computers that have no USB access or network access. Note TFS on its own, or Hg or Git or SVN doesn't solve that. VPN makes unaudited access to code trivial.

What you really need is the Windows Shell Plugin:

I think that downloads everything you'll need, including the Mercurial package it runs.

In case I'm wrong on that score:

Don't have a link right now…but know at least this.

  • You Clone the totality of a Repository (not a subbranch as one would with SVN).
  • You clone it from a place on the web or another folder, to a local folder.
  • You expand the repo you cloned, and work against that.
  • When done, you checkin changes to your local repo.
  • Normally, with Subversion, that's it. But with Mercurial, you havn't yet uploaded the changes to a remote server.
  • This is a good thing. It allows you incrementally commit, while not uploading until you have it running again…
  • When ready, you right click on the repo, and use TortoiseSVN's Workspace to Sync the folder back up.


If using it with a clone of XActLib...take it easy. Read up on Mercurial whatever you >publish back to bitbucket.or will be shared by others (it's a public Repo after all).

Right after cloning from to local hd, I do the following:

Edit the .hg/hgrc file within the repo to define where my ignore file is, and my default username:

  ignore = ~/.hgignore    
  username = skysigal
  postpull = update
  autoresolve = False

That setting relies on a shared %USERPROFILE%\.hgignore file that I create and contains:

  \# use glob syntax.
In Windows, it's difficult to create a file that has no filename.
See: [[IT/AD/Mercurial/HowTo/Create an Ignore Filter File]]

That also relies on %USERPROFILE%\mercurial.ini containing:

cipushafter = default-push
postpull = update
closeci = True
engmsg = True

username = skysigal
merge = diffmerge

CS.FF.XAct.Lib.prefix =
CS.FF.XAct.Lib.username = ****
CS.FF.XAct.Lib.password = ****

commit.autopush = hg push

host = CORPwgpx1:80
user = CORP\Sky    
passwd = XXXXXX
As for settings, I guess it's a matter of preferences. So these are just my preferences...

Select a Repo, and edit settings:

  • Global Settings:
    • Commit:
      • UserName: skysigal
      • Set 'Close After Commit'
    • Proxy
      • Host: CORPwgpx1:80
      • User: CORP\Sky
      • Password: XXXXXX

    In a corporate environment, you need to set the Proxy. This too is in %USERPROFILE%\mercurial.ini:

    [http_proxy] host = CORPwgpx1:80 user = CORP\Sky passwd = Passw0rd1 [auth] CS.FF.XAct.Lib.prefix = CS.FF.XAct.Lib.username = skysigal CS.FF.XAct.Lib.password = XXXXXX

    [hooks] commit.autopush = hg push

To get out from TeamCity, I used:

 hg --config http_proxy.user=DEVXX\Sky http_proxy.passwd=XYZ

Don't think so. The exact text includes “Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS”:

When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS. We thought hard about building something. Git hasn’t been as friendly for Windows developers as on other platforms. By building on Git, we can take all the time we might spend just “catching up” and spend that effort on something where we can add more distinctive value. Choosing Git just made sense.