Move Mercurial Repository To Another Server

Question

We have a project that lives in a mercurial repository.

Our customer would like to take ownership of the code base by doing the following:

1. Set up a mercurial repository on a server belonging to the customer.
2. Import the existing code into the new mercurial repository.

What is the best way to achieve step 2?

Is it a simple matter of doing the following:

1. Clone the existing mercurial repository:

   hg clone <existing mercurial repo URL>
   

2. Push the cloned repository into the new one:

   hg push <new mercurial repo URL>
   

Am I missing any steps? What about the hgrc file? Does it have to be modified in any way prior to pushing the project into a new repository?

Answer 1

Yes, you can do what you state, however it is worth noting that if you do a simple hg clone of your main repository, then a link will exist between the two, which may not be what you want. You can remove this link by editing the .hg/hgrc file and removing the default = ... item in the [paths] section.

I find that a better way is to do it without cloning. This way you don't have the link between repositories, which as this is going to a customer may be what you want.

The basic method is to set up a new repository with no changesets, and then bring in all of the changesets in one of three ways:

1. Push the changes from your repository to the new repository.
2. Pull the changes from into the new repository from the old.
3. If you don't have access to the new repository, create a bundle that can be provided to the customer - this can then be unbundled or pulled into the empty repo.

Pushing and Pulling is done as you normally would, but specifying the repository location:

// create the empty repository
hg init .
// pull in everything from the old repo
hg pull /projects/myOriginalRepo

or to push...

// create the empty repository
hg init /projects/myNewRepo
cd /projects/myOriginalRepo
hg push /projects/myNewRepo

Creating a bundle is perhaps a nicer way, as you can write the bundle onto a DVD and give it to your customer wrapped in a bow with a nice greeting card:

cd /projects/myOriginalRepo
hg bundle --all ../repo.bundle

Everything gets written out to a single file, which can then be extracted with hg unbundle repo.bundle or hg pull repo.bundle, into a repository with no existing changesets.

Regarding the hgrc file, as already mentioned in another answer it is not a controlled file, and so won't be copied. However, any contents are likely things like hooks to perform auto-building, or validating changesets before they are applied. This is logic which would probably only make sense to your own organisation, and I would suggest you wouldn't want this to be imposed on your customer - they are, after all, taking ownership of your code-base, and may have their own systems in place for things like this.

Answer 2

In the simple case - it's all.

But if you have modified .hg/hgrc file then you need to move it to the remote server manually and (if necessary) modify it correspondingly to a new environment.

Ie: you could have hooks set up in the original repository.

As of clients - just change a path to a repository in a default section (or any other section if you have several specified)