eWorld.UI - Matt Hawley

Ramblings of Matt

Setting up Mercurial server in IIS7 using a ISAPI module

April 8, 2010 18:10 by matthaw
In addition to blogging, I'm also using Twitter. Follow me @matthawley

 

Previously, Jeremy Skinner posted a very thorough guide on setting up Mercurial in IIS. The difference between his guide, and what I'll be walking you through, is how Mercurial is hosted in IIS. Where he shows you using a CGI script that executes python.exe, my guide will show you how to use isapi-wsgi to host Mercurial. The biggest benefits of using isapi-wsgi over executing python.exe, is the raw processing speed and the overall throughput your server can handle.

 

Note: This post uses Mercurial 1.5.1, Python 2.6.5 although it should work for all older/future versions released.

 

Packages Installation

 

Install Python

The reason you need to install Python first, is that all subsequent installations will install directly into the Python installation (in the Lib\site-packages folder), including Mercurial. It is important to note that you will need to install the version of Python that Mercurial was built against, as well as installing the x86 version (yes, even if you're on a x64 platform). Download and install Python 2.6.5.

 

Install PyWin32

This component is needed to run certain win32 functions (specifically for ISAPI) that isapi-wsgi needs. Download and install this package, letting it determine the default installation path for you.

 

Install Mercurial Source

Normally, you would download the binary package for Mercurial, but for this process to work, you will need to utilize the source code package. Download the mercurial-1.5.1.win32-py2.6.exe package and install it. Just as PyWin32, let it determine the default installation path for you.

 

Install isapi-wsgi

This is the glue that binds everything together. It's used to build a shim based on a python script that you setup (later). Download and install this package, also letting it determine the default installation path for you.

 

Get hgwebdir_wsgi

You will now need to download the python script hgwebdir_wsgi.py. This is the script that you will configure to and execute to build the ISAPI shim DLL. This script is apart of the Mercurial source code, and is not distributed with the binaries or the earlier installation. To get it, you can download the source code from the Mercurial site, or clone their repository by executing the following command

hg clone http://selenic.com/repo/hg#stable

Once you have the source, you can find the script in the contrib/win32 directory.

 

image

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuration


Note: The following steps assume that you already have IIS installed. If you do not, please refer to Jeremy's guide for these steps.

 

1. Create a folder that will be used by the IIS website for hosting your Mercurial installation. For example, C:\inetpub\hg

2. Copy hgwebdir_wsgi.py to the location created in step 1

3. Open hgwebdir_wsgi.py in a text editor, and configure the following settings

hgweb_config = r'c:\inetpub\hg\hgweb.config' 
path_prefix = 0

4. Open a command prompt changing your directory to c:\inetpub\hg

5. Execute python hgwebdir_wsgi.py which will generate a DLL shim called _hgwebdir_wsgi.dll

6. Create your hgweb.config file with the following content

[paths]
/ = c:\repos\*

7. In IIS Manager, create a new application pool called "Mercurial" and ensure that the "Enable 32-bit Applications" is set to true.

 

image

 

8. Create a new website pointing it to the location in step 1.

 

image

 

9. Open up the Handler Mappings for your new web site.

 

image

 

10. Add a new "Wildcard Script Map" with the Executable location pointing to the Shim DLL created in step 5. Give it the name Mercurial-ISAPI.

 

image

 

11. Click the OK button, and when it prompts you to allow this ISAPI extension, click "Yes".

 

image

 

12. Now, browse to your newly created website, and you should see hgwebdir being served.

 

image

 

13. Now, run the following command to create a new empty repository, and then refresh your browser.

hg init c:\repos\test
image

 

All Setup!

 

At this point, your Mercurial server is setup. You'll also notice that there's no need for URL rewriting unlike the the CGI approach. You can start pulling / pushing changes to your repository. While this setup requires more steps and dependencies, the benefit is that you are running completely within IIS gaining it's benefits of application isolation, memory management, and improved performance.



Categories: Mercurial
Actions: E-mail | Permalink | Comments (28) | Comment RSSRSS comment feed

Mercurial Conversion from Team Foundation Server

March 16, 2010 09:12 by matthaw
In addition to blogging, I'm also using Twitter. Follow me @matthawley

One of my many (almost) daily tasks when working on the CodePlex platform since releasing Mercurial as a supported version control system, is converting projects from Team Foundation Server (TFS) to Mercurial. I'm happy to say that of all the conversions I have done since mid-January, the success rate of migrating full source history is about 95%. To get to this success point, I have had to learn and refine several techniques utilizing a few different tools to get the job done. Before I jump into the meat of the post, there are several setup tasks that need to be done first.

 

Configuring Mercurial

Mercurial comes with a pre-packaged extension, convert, which supports nearly all major version control systems (Subversion, CVS, git, Darcs, Bazaar, Monotone, GNU Arch, and yes - even itself). Because this is an extension, you need to enable it in the Mercurial configuration. Open the Mercurial.ini file located at C:\Users\<UserName> and add the following lines

[extensions]
convert =

Once this is saved, you can test if this extension is working by typing the command hg help convert If things are configured correctly, it should display the help information regarding the convert extension.

 

Conversion Setup

Mercurial's convert extension allows you to have somewhat full control when performing the conversion. These options include mapping usernames, including/excluding certain paths, and renaming branches. These configuration options are to our advantage since TFS requires Active Directory and stores all commits in the format of DOMAIN\User (though this format is perfectly acceptable, it's not ideal). Utilizing the ability to map usernames, create a new text file named auths.txt and start adding your mappings:

CONTOSO\Joe = Joe
CONTOSO\Mark = Mark

It is only necessary to add username mappings that appear in the TFS source history. Later, you will see how this username mapping file is used.

 

Utilizing SvnBridge

The first approach I take for doing project conversion for CodePlex, which has a success rate of 85%, is using the hosted SvnBridge. From the command line type the following

hg convert --authors auth.txt https://xunitcontrib.svn.codeplex.com/svn xunitcontrib

If the conversion works, your project will be successfully converted to Mercurial. It is recommended that you view the log history to ensure everything is in order. Should anyone continue to check in sources, just re-run the conversion on the already-converted Mercurial repository, and it will convert anything new.

 

Utilizing A Suite of Tools

Should the hosted SvnBridge not work, or you have TFS hosted elsewhere, the process is not nearly as straight forward and requires the use of several tools. Download and install the following

  • tfs2svn - This converts TFS history into Subversion history
  • VisualSVN Server - Used as the intermediary Subversion repository store
  • TortoiseSVN - Used for storing the Subversion credentials as well as admin tasks

After you have installed all of these tools (and probably rebooted your machine), follow these steps.

 

Step 1: Create an empty repository in VisualSVN Server. This is where the history from TFS will be migrated to as an intermediary step. Make sure that you do not select Create default structure (trunk, branches, tags). If you accidently check this option your import via tfs2svn will fail because it is expecting an empty repository.

 

Step 2: On the newly created repository open the Manage Hooks dialog by Right Clicking Repository -> All Tasks -> Manage Hooks... Edit the Pre-revision property change hook by entering a single carriage return. This is necessary for enabling hook which allows tfs2svn to rewrite the history in Subversion. If the hook is enabled correctly, it will become bolded in the list of available hooks. Click OK to discard the dialog, and restart the VisualSVN server by Right Clicking VisualSVN Server -> Restart

 

Step 3: You now need to add a user account to VisualSVN server so that tfs2svn can authenticate and import the history. In VisualSVN, right click Users and select Create User. Type in a easy-to-remember username and password and click OK. How tfs2svn operates, is that it uses cached Subversion credentials for the import. The easiest way of caching your credentials, is checking out your new Subversion repository. When prompted for credentials, ensure the checkbox Save Authentication is checked.

 

Step 4: Launch tfs2svn and start filling in the connection information to your TFS and Subversion servers. Once the information is correctly filled out, click the Convert button and wait while it starts extracting the history from TFS and importing it into your Subversion repository.

 

image

Step 5: Once the tfs2svn process has been completed, you can view the history of the Subversion repository. One thing you'll notice, is that tfs2svn prefixes all commit messages with "[TFS Changeset #12345]". There are also some instances where tfs2svn will add "tfs2svn: " as a commit message as well. If you don't care if your Mercurial repository will have these messages, skip to step 6 - otherwise continue on.

 

image 

To remove the erroneous commit messages, you will need to rewrite the Subversion log using administrative tools. The process follows

  1. Get an XML log of the repository history
  2. For each logentry in the XML log get the msg content and remove the messages
  3. Create a temporary file writing the updated log message to it
  4. Call the setlog command on the executable svnadmin passing in the path to the temporary file in step 3.

As you can see, this is a tedious process - so I automated it with a Powershell script (downloadable here). The script assumes that your VisualSVN server can be accessed at https://localhost/svn/<RepositoryName> as well as the physical path of your VisualSVN repositories are located at C:\Repositories. Once you have updated the script, place it in %My Documents%\WindowsPowerShell, open a Powershell command prompt and type rewrite-log RepositoryName

Note: If you view the Subversion log again, you may notice that the message for each revision still contains the content we were trying to strip off. If this is the case, don't worry - the history has been rewritten, and you may be viewing a cached version of the repository.

 

Step 6: Now that you have your repository migrated to Subversion and you have rewritten the log , you can now convert it into a Mercurial repository. Using the same syntax as SvnBridge conversion earlier, type the following on you command line

hg convert --authors auth.txt https://localhost/svn/xunitcontrib xunitcontrib

image

 

Once completed, you will have a full history of your TFS repository converted to Mercurial! You can now start using your local repository immediately or push the history to a central repository for others to start using.

 

kick it on DotNetKicks.com

VisualHG: A Mercurial Plugin for Visual Studio

March 15, 2010 12:03 by matthaw
In addition to blogging, I'm also using Twitter. Follow me @matthawley

 

imageMercurial is quickly gaining momentum in the open source world, and the need for great tooling to make developers lives easier is always essential.  Most developers using Mercurial know of the the explorer shell plugin, TortoiseHg, but what many don't know about is VisualHG. In summary, VisualHG is

  • A source control plugin for Visual Studio (works with 2005, 2008 and 2010)
  • It sits on top TortoiseHg exposing common commands in Visual Studio
  • It tracks file status changes automatically indicating the state in Visual Studio
  • There's absolutely no SCC bindings!
  • It's absolutely free!

An occasional gripe we hear from CodePlex users, is that when they download and open a project from CodePlex that contains SCC bindings, they quickly get annoyed by the Visual Studio warnings of working temporarily uncontrolled. This is why the second to last bullet point is even listed, it's that important! The mere fact that it's free is just a bonus :)

 

To get started working with VisualHG is very simple.

  1. Download and install TortoiseHg and VisualHG.
  2. Open Visual Studio and go to Tools -> Options.
  3. In the options tree view, select Source Control. (You may need to click the Show all Settings checkbox)
  4. Select VisualHG from the drop down list, and click OK.
  5. Open your Mercurial based solution to see the plugin installed and determining your files' statuses.

So, why am I writing this post? Well, I wanted to highlight and recommend a great Mercurial based project hosted on CodePlex that we, the CodePlex team, use every day. Don't get me wrong, a few of us still use Mercurial from the command line (myself included), but I wouldn't even go without having VisualHG installed for simply tracking file status changes (necessary when doing lots of refactoring).

 

kick it on DotNetKicks.com





Copyright © 2000 - 2014 , Excentrics World