Build a free distributed project hosting using Mercurial and Windows Live Mesh
For a small distributed project team, for example, a two-person’s team moonlighting for Windows Phone 7 applications/games, it is not necessarily a simply job to find a free or low-cost private/close source project hosting service: either they are too unreliable, or they come with too many limitations, and of course, the ads. Thus, besides getting a higher priced premiere hosting service, it seems the only alternative is to build a revision control system yourselves. This post introduces an easy way to setup such a versioning service, which can be used by every developers from the project team who doesn’t necessarily have direct connections together: The MercurialMesh (Mercurial + Windows Live Mesh).
Mercurial is a cross-platform, distributed revision control software released under GNU GPL [MERC] . It is adopted as the core part of this versioning service because of Mercurial’s distributed architecture. For developers to share changes, Windows Live Mesh Service is used to synchronize different distributed repositories among each others. Windows Live Mesh Service is a free Internet-based file synchronization service [WLM11] , and it eliminates the needs of exposing an webserver on the Internet yourself for sharing changes, or manually sending changes to each others by emails.
How to Setup
1. Install Windows Live Mesh Service [WLM11]
2. Install Mercurial [MERC]
After both software have been stored, the only thing you need to do is to setup the master copy of your Mercurial repository and mark it as sync-able by Windows Live Mesh
3. To create master copy of your Mercurial repository, use command “hg init path_to_your_project_folder”. This command will initialize a new repository in that given path. If the given path doesn’t exist, it creates one. For example:
C:\Projects>hg init myproject_master
C:\Projects>cd myproject_master
C:\Projects\myproject_master>dir
Volume in drive C has no label.
Volume Serial Number is 486B-D984 Directory of C:\Projects\myproject_master
26/10/2010 03:30 Ale <DIR> .
26/10/2010 03:30 Ale <DIR> ..
26/10/2010 03:30 Ale <DIR> .hg
0 File(s) 0 bytes
3 Dir(s) 131,480,449,024 bytes free
4. Create a new Mercurial configuration file hgrc inside the .hg folder under your newly created repository. Open hgrc and specify a username you like for master repository by adding the following line:
[ui]
username = maintainer <maintainer@greatteam.com>
Note: If you are using an existing folder with files inside, you can now add those files into the master repository by using command: “hg add” and then followed by “hg commit”.
Now the master repository is ready, and then the next step is to mark the master repository to be synchronized by Windows Live Mesh. After initial setup, the master repository must not be worked on directly, so this user account is used only for maintenance and recovery purposes.
5. Open Windows Live Mesh window, use “Sync a folder” option to add the folder where the master repository is to Windows Live Mesh. And then use “Shared with” option to give other developers the permissions to sync the same folder.
When you get here, the setup of your MercurialMesh versioing service is finished, You can start to use it
How to Use
First, every developer should accept the sharing invitation sent by Windows Live Mesh, so that every one will have a master repository synced on his/her machine.
Create enlistment:
This is to create a local working copy of the master repository. Use command: “hg clone master_copy local_copy” , for example,
C:\Projects>hg clone c:\Projects\myproject_master c:\Projects\myproject_local
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Open hgrc inside the .hg folder of your newly created local repository, and specify a username for yourself adding the following line:
[ui]
username = Alice <alice@greatteam.com>
Note: Every developer must work on their own local repository, NOT on the master repository, otherwise, the revision history could be altered in an unwanted way
Getting the latest changes from others:
This is to update your local repository with the latest changes which have been submit to master repository by other developers
1. (Optional) Use “hg incoming” to see what new changes are in the master repository, for example:
C:\Projects\myproject_local>hg incoming ..\myproject_master
comparing with ..\myproject_master
changeset: 0:40aa6d24fb24
tag: tip
user: maintainer <maintainer@greatteam.com>
date: Tue Oct 26 15:59:31 2010 -0700
summary: Init master repro with helloworld
2. Once you confirm that you need to get those changes, use “hg pull” to get those new changes, for example:
C:\Projects\myproject_local>hg pull ..\myproject_master
pulling from ..\myproject_master
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
3. Don’t forget to apply those changes using “hg update” to your local repository. for example:
C:\Projects\myproject_local>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Note: “hg update” is the command actually modify your local files with those changes. Without “hg update” those new changes are just kept inside the Mercurial’s cache files, and they are not visible to you directly
Submit your changes to others:
This is to submit your local changes into master repository, so other developer can received your changes later on if they uses “hg pull”
1. (Optional) Use “hg status” to confirm the list of files you intend to change, for example:
C:\Projects\myproject_local>hg status
M helloworld.cpp
2. Submit the change to your local repository first by using “hg commit”, for example,
C:\Projects\myproject_local>hg commit
3. (Optional) See how is your change looks like to master repro by using “hg outgoing” command, for example:
C:\Projects\myproject_local>hg outgoing ..\myproject_master
comparing with ..\myproject_master
searching for changes
changeset: 1:0cd5548b8bbe
tag: tip
user: Alice <alice@greatteam.com>
date: Tue Oct 26 16:06:19 2010 -0700
summary: Fix alignment
4. Make your local change into master repository by using “hg push” command, for example:
C:\Projects\myproject_local>hg push ..\myproject_master
pushing to ..\myproject_master
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
Now your change is in the repository, and available to others who choose to “hg pull”
View the history:
See the revision history of your project, use “hg log” command, for example:
C:\Projects\myproject_local>hg log
changeset: 1:0cd5548b8bbe
tag: tip
user: Alice <alice@greatteam.com>
date: Tue Oct 26 16:06:19 2010 -0700
summary: Fix alignment
changeset: 0:40aa6d24fb24
user: maintainer <maintainer@greatteam.com>
date: Tue Oct 26 15:59:31 2010 -0700
summary: Init master repro with helloworld
And more:
There are more much things you can do using Mercurial as you expected from any other distributed revision control system, such like merging and conflict resolving etc. See more usage at Mercurial site [MERC] . If you prefer GUI to command line window, TortoiseHg is good choice. And if you want even more integration with Visual Studio, then install VisualHg on top of TortoiseHg.
Also, you can enable Windows Live Mesh to sync your master repository with your Windows Live SkyDrive. That will keep a copy of your master repository in Microsoft’s cloud storage space. For that, you will give your repository the same availability as Microsoft Live SkyDrive promised
Summary
MercurialMesh (Mercurial + Windows Live Mesh) is very straightforward to setup. Basically, Mercurial is used for revision control, and Windows Live Mesh is used to share changes among developers. It is easy for daily use too: “hg pull” + “hg update” to receive changes from others; “hg commit” + “hg push” to submit your changes. This system costs your nothing, and it doesn’t requires any additional infrastructure setup, such like DNS Name, firewall and web server etc. For a small size team with infrequent changes exchange, it just simply works.
However, the scalability of this setup yet to be tested. There is a considerable delay between when a new change being made to master repository and when Windows Live Mesh finishes the sync.
References