Does the .hg folder need to reside on the working directory?

Question

I am new to Mercurial. I was wondering if there is a way to move the .hg folder to another location than the working directory and still monitor changes?

For example,

I have the .hg in /foo/.hg/*
Can I move it to  /bar/.hg/* and still monitor the contents of foo?

Edit: I am paranoid about working directory. I have the Dropbox backup my Mercurial repository. But the .hg folder is getting too big for my Dropbox

Answer 1

No, you cannot. If you can explain why you want to do this, I may be able to help you figure out a different solution.

Also, you can have subdirectories in foo, and they do not each have to have their own .hg directories. Only the top-level directory of the tree managed by Mercurial needs a .hg directory.

If your concern is backup, the solution is simple. Clone your repository to a directory you never do anything in and push to the clone periodically. Mercurial's system of using cryptographic hashes for things will ensure that your repository never becomes corrupted in a way that a push silently succeeds and corrupts your backup repository.

If you want an 'offsite' backup, use a hosting service like bitbucket , or even just a repository cloned into a USB stick.

I must have 5 or 10 copies of almost all my repositories lying around in various places. I use push and pull to keep them in sync, and if I lose one, it's likely I've not lost any of the changes in it. I rm -rf working directories regularly without worry.

Answer 2

You should not, emphatically not put your repositories, of any kind, in any kind of synchronization system, be it Microsoft Live Sync (which is going away btw), Microsoft Live Mesh, DropBox, or whatever.

Basically you're asking for trouble. The various synchronization tools cannot guarantee that you won't be able to change one of the files before it has managed to synchronize, and if you manage to change files on more than one machine before DropBox synchronizes, you'll get synchronization conflict, which might very well just make your entire repository corrupt beyond hope of repair.

If, as you say, you're paranoid about your files, dropbox should be the last "solution" you would want to pick. It's almost guaranteed to go wrong at some point.

Instead, get an account with a hosted provider, like bitbucket and place your repository master there, then just pull down to the machines you use. Bitbucket has support for private repositories, which aren't open to the public, and should be no less secure than you placing your repository in a dropbox account.

This will avoid getting in trouble with the size through any of the synchronization tools, and you don't have to worry about repository corruption.

So don't do it!

As for moving the .hg directory, unless you're using a development environment which won't leave those files alone, there should be no need to move it.

Answer 3

The answer to your actual question is no, but there is a solution to your problem. I'm guessing the real issue is that you are afraid of losing uncommited work. While the other posters are correct that you should be comitting and pushing to a remote repository regularly (use bookmarks if you don't want to branch), you can also backup the dirty working copy status, with uncommited work on dropbox by using the trick in the following link:

http://www.dropboxwiki.com/tips-and-tricks/exclude-folders-from-syncing

This link explains how to exclude certain folders from syncing by dropbox while retaining their local contents.

You could apply this solution to the .hg folder in your cloned repository, so it is ignored. If doing this, I would also create a subfolder in dropbox specific to each computer you work on to clone your repos into, and don't use the same one on multiple computers for obvious reasons.

This is of course only a last resort disaster protection system, and it will only backup the instantaneous state of your working copy, not any unpushed commits etc. Thus it should never be saving you more than, say, half a day's work at any time.