CODEWITHSUNDEEP
mercurialproject-managementredmine
max
max

Reputation: 52343

Using one Mercurial repository as local for two Mercurial installations

We have a dedicated issue tracking (Redmine) machine, which has a Mercurial repository (call it "Redmine repository"). Redmine is set up to use that repository, and as far as I understand, Redmine never makes any changes to that repository. All developers (eventually) push their changes to that repository.

We also have a dedicated production machine, which can execute the code, but is not used to make any changes to the code.

We have two choices:

  1. Set up another Mercurial repository on the production machine (call it "production repository"). When a new production release is approved, pull the changes from the Redmine repository to the production repository, and then update the local working directory to the appropriate revision from the production repository.

  2. Reuse the existing Redmine repository on the production machine designating it a local repository for the Mercurial installation there (the Redmine repository is on the shared drive that can be easily mounted on the production machine). Whenever a new production is approved, update the local working directory to the appropriate revision from the Redmine repository.

With option #2, we get rid of an extra "pull" step (from Redmine repository to production repository), which slightly simplifies the process. But I'm not sure if it's ok that a single repository is used by two Mercurial installations as if it's local.

Any comments on this choice (or any other aspect of this setup) is appreciated!

Upvotes: 2

Views: 188

Answers (1)

Ry4an Brase
Ry4an Brase

Reputation: 78350

It sounds like a bad idea. Mercurial does a really good job of keeping reads and writes to its repository atomic, but it has a harder time doing that when the repository is on a shared drive -- even if it's only one local repository using it -- because network shares (especially on Windows) don't always make things atomic that they say they do.

Ideally your repositories (both the working dir and the repository) are local when possible, and you use push/pull to get changesets to/from a network share. If that's not possible then having a single local application using the repo on the remote file system is the best idea.

If you positively want to try having two clones using the same underlying repository check out the ShareExtension, which ships with Mercurial but is for advanced users only.

Instead of trying to piggy-back, why not just put a hook like this in your redmine repository:

[hooks]
changegroup = hg push //production/clone

That will automatically push changesets that arrive in redmine to production.

Upvotes: 4

Related Questions