Compartir a través de


CodePlex now supporting native Mercurial

What is Mercurial?

Mercurial is a distributed source control management system. For new projects created on CodePlex.com, you will be able to choose from either Team Foundation Server or Mercurial as your source control repository.

To illustrate, in the Create a Project wizard you’ll see the following:

Mercurial as a Source Control option

If you are a current project owner and wish to switch to Mercurial, please contact us at CodePlex Support with your project name, and we’ll be glad to help you out.

Why DVCS?

Adding distributed version control support to CodePlex has become a top feature request from users, as the popularity of DVCS for open source development has grown significantly. Mercurial is one of the most popular distributed version control systems and offers great support for Windows based tools as well as works very well as a hosted service.

If you are new to Distributed Source Control Systems, please read this section!

Mercurial is a Distributed Version Control System (DVCS). Unlike Team Foundation Server, DVCS has a very different model for collaborating on an open source project.

  • In DVCS, you do not check in and out changes. You check in and out the entire set of changes (aka the repository).

To get started, you firstmake a local copy of the repository, or clone the repository. In TFS speak, this is the equivalent of getting the entire history (source code + metadata) of each and every change set in source control. It is literally making a copy of everything you see in the CodePlex source control. Since you are copying the entire repository, there isn’t a notion of “checking out”.

  • In DVCS, you commit to the local repository, and push your changes back to CodePlex.

Since you have your own repository, you “check in” by committing to your local repository. Once you’ve committed locally, you can “check in” those changes back to CodePlex by pushing those changes.Hence the term “check in” doesn’t apply because it is overloaded in the DVCS context.

A quick recap:

  • Anyone can clone. (Create local repository, Get all change sets from repository)
  • Anyone can commit. (Check-in to their local repository)
  • Anyone can pull. (Get all change sets from repository)
  • Only team can push. (check-in of local repository to CodePlex)

See our post Using Mercurial on CodePlex for a step-by-step walkthrough.

Comments

  • Anonymous
    January 22, 2010
    Great I remebered voting for the feature (actually git). Any plans for Git on codeplex?

  • Anonymous
    January 24, 2010
    Why not Git? It's because github beat you to it, isn't it?

  • Anonymous
    January 24, 2010
    While in my opinion DVCS brings little improvement for companies where the user has access via the local network having a central point of submission DVCS is great for open source projects. Especially because the user is able to do check-ins on projects without write access (e.g. when creating a patch for a third party tool/lib). Thanks a lot for this great improvement on open-source development from MS side. Greetz Felix

  • Anonymous
    January 25, 2010
    @clark good question, but your guess sounds like it is a bit filled by hate... what does not speak for the use of git? so long identity

  • Anonymous
    January 25, 2010
    Any chance you will implement a feature where users can create a remote forked branch and enable the users to submit a patch by submitting pulling in their forked changes?  This is the feature that makes GitHub so powerful to OSS.  The ease of contributing large / non trivial features.  Doing this using patch files is not only cumbersome but actually becomes difficult when keeping everything up to date. The patch can go stale while it is waiting to be reviewed.   I would love to bring the source control for MvcContrib back to codeplex from github.com but I cannot justify losing the great contribution model that comes from allowing users to fork and send remote pull requests to the project team.  Any thoughts on this?   You all are so close with Hg.

  • Anonymous
    January 25, 2010
    Congrats guys! I was waiting this!

  • Anonymous
    January 25, 2010
    @clark why do you need git? mercurial is better in almost any way.

  • Anonymous
    January 27, 2010
    git is better in every way. Look at the speed comparisons and adoption rate.

  • Anonymous
    January 30, 2010
    Just to thank you for incorporate Mercurial support, I use it on several projects.

  • Anonymous
    January 31, 2010
    This is really good. One of the things that has been a real issue working on a codeplex project (minisqlquery.codeplex.com) has been making a bunch of changes disconnected and having to juggle those checkins when you are online as a big lump. Having that local repository will be great - should be "upgrading" soon!   PK   :-)

  • Anonymous
    February 02, 2010
    Out of curiosity, why was Mercurial picked instead of git? I like Mercurial better than git but the latter  seems to be more popular in .NET community in general so I'm wondering if there were some backend issues with it or something? Anyway, it's great to see distributed version control system supported on CodePlex, it was an unexpected move to me.

  • Anonymous
    February 05, 2010
    The comment has been removed

  • Anonymous
    February 16, 2010
    Any chance codeplex will get native Subversion support? The bridge still doesn't support branch/merge.

  • Anonymous
    February 17, 2010
    It would have been really cool if you guys had used GitSharp ( http://www.eqqon.com/index.php/GitSharp ) to add git support to codeplex. Well, you still can of course :-)

  • Anonymous
    February 21, 2010
    Congratulations on such a superb feature! Poor svn support and lack of DCVS was one of the reasons to partly move out my project from CodePlex. Mercurial support is great!

  • Anonymous
    February 28, 2010
    Nice addition! Any likelyhood of native SVN in the coming year as well?

  • Anonymous
    April 27, 2010
    I speculate that one reason Mercurial was chosen over Git because it isn't a port from Linux. It was actually meant to run on Windows from the beginning.