I am thinking on creating a Mercurial repository under a Git repository.
e.g.

..../git-repository/directory/hg-repo/

The 2 repositories

Is it possible to manage (keeping your sanity)? How similiar is it to this?

I am a computer science student at University. I manage my work in Git, mainly as a distribution mechanism (after realizing that rsync fails when you have changes in more than one place) between my desktop and usb drive. I try use of Git as a VCS as I do work.

I have finished a semester where I did a small group project to prepare for a larger group project next year. We had to use Subversion, and experienced the joys of a centralised VCS (including downtime).

I tried to keep the subversion repository separate to my Git repository for the subject**, however it was annoying that it was seperate (not in the place where I store assignments). I therefore moved to using an Subversion repository inside my Git repository.

As I think ahead (maybe I am thinking too far ahead) I realise that I will have to try and convince people to use a DVCS and Mercurial will probably be the one that is preferred (Windows and Mac GUI support, closer to Subversion).

Having done some research into the whole Git vs Mercurial debate (however not used Mercurial at all) I still prefer Git.

Can I have a Mercurial repository inside a Git one without going mad (or it ruining something)? Or is it something that I should not consider at all?

4 Answers
4

Take a look at the hg-git extension for Mercurial, http://hg-git.github.com/. It allows you to access a Git repository (including pulling, pushing, and committing) using Mercurial. I use it to manage my projects on Github using TortoiseHg on Windows. Haven't had a problem with this approach yet.

The Convert extension converts repositories from other SCMs (or even Mercurial itself) into Mercurial repositories, with options for filtering and renaming. It can also be used to filter Mercurial repositories to get subsets of an existing one.

The current release supports the following repository types as sources:

I've done similar things when transitioning projects. I wouldn't particularly recommend it -- there is just always a landline to step on and it definitely takes some options off the table. I would just use hg for the project and transfer the final bit into git when it is done.

On the technical side make sure you ignore the .hg folder and other hg artifacts. That at least gives you a fighting chance.

For file transfer/synchronization/distribution, you might want to try Unison instead of git.

Unison is a file-synchronization tool for Unix and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other.

Unison shares a number of features with tools such as configuration management packages (CVS, PRCS, Subversion, BitKeeper, etc.), distributed filesystems (Coda, etc.), uni-directional mirroring utilities (rsync, etc.), and other synchronizers (Intellisync, Reconcile, etc). However, there are several points where it differs:

Unison runs on both Windows and many flavors of Unix (Solaris, Linux, OS X, etc.) systems. Moreover, Unison works across platforms, allowing you to synchronize a Windows laptop with a Unix server, for example.

Unlike simple mirroring or backup utilities, Unison can deal with updates to both replicas of a distributed directory structure. Updates that do not conflict are propagated automatically. Conflicting updates are detected and displayed.

Unlike a distributed filesystem, Unison is a user-level program: there is no need to modify the kernel or to have superuser privileges on either host.

Unison works between any pair of machines connected to the internet, communicating over either a direct socket link or tunneling over an encrypted ssh connection. It is careful with network bandwidth, and runs well over slow links such as PPP connections. Transfers of small updates to large files are optimized using a compression protocol similar to rsync.

Unison is resilient to failure. It is careful to leave the replicas and its own private structures in a sensible state at all times, even in case of abnormal termination or communication failures.

Unison has a clear and precise specification.

Unison is free; full source code is available under the GNU Public License...