Should we occasionally "upgrade" our Mercurial repositories as new versions of Mercurial come out? - mercurial

Are there some reasons to occasionally upgrade mercurial repositories using the instructions in Upgrading Mercurial (hg clone --pull)
Does advice about that differ for the repositories I keep on my laptop, versus the central shared repository for a project/continuous integration/etc. (For instance, could we run into problems if one developer has an old version of the client?)
And how do you tell what version's format a repository was built with, and whether there's something to be gained?

Unless you are using an extremely large repository (something on the scale of the mozilla-central repository) it shouldn't matter what repository format you are using on the client or server. Future versions of mercurial will always be able to talk to repositories created by old versions and old versions will be able to pull from repositories created by new versions of mercurial.

Related

Kiln Mercurial Repositories for Versions

we use Kiln with mercurial.
Simplified description we have 2 kind of Repositories.
Some Kind of
"CurrentDevelopment" and repositories for each released version for example 13.1 for the released version 13.1. (There are also user repos and more, like descriped in hginit.com but this can be ignored for the moment)
Now sometimes we need to make a fix to a released version. So we fix it in the Repository for the released version. For 13.1.
Then we cann pull from 13.1 to the currentDevelopment repository
This seems to work fine.
But now we could make something in "CurrentDevelopment" and a month later we recognize that this change will also be needed in 13.1 But I can't pull from CurrentDevelopment to 13.1 because there are a lot of other changes i don't want to have in 13.1
I know this is some kind of "cherry picking" which i isn'T easy realized. But if it wouldn't be many source code i code recode them in 13.1.
But after that when i make changes to 13.1 which i pull to current development i would also pull the changes that are already included in CurrentDevelopment :-/ so in worst case i may get merge failures and duplicate code? I'm not sure if mercurial will safely recognize that this code is also contained.
What is the recommended approach to realise these version specific repositories and handle changes between them ? In especial if a change of the current development repository is afterwards needed in a child verison branch?
The graft mercurial command is your friend here.
It allows you to back-port a change to an old branch.
If your Kiln version is older & doesn't have a version of Mercurial that includes the graft command, you could use the (similar but less reliable) transplant extension.
(graft uses Mercurial's merge logic, transplant just uses the patch logic)
edit...
I don't think that graft command is exposed in the UI of the version of TortoiseHg that is currently bundled with Kiln. See how to use graft in TortoiseHg
The command line should still work though.

Is it possible/recommended to install TortoiseHg if (a newer) mercurial is already installed?

I have searched the docs and it is still unclear to me if I can install TortoiseHG on a machine where mercurial is already installed. In particular I find in the FAQs that the installer bundles Mercurial. But, on the other hand, to build from source requires (obviously) to hg clone the repository.
My problem is that I installed the latest release of Mercurial (which, as of Nov 2012, is 2.4) while all the currently available THG releases refer to previous versions. For instance,
2012-10-01: TortoiseHg 2.5.1 (with Mercurial 2.3.2) released
as can be seen in the news as of Nov 2012.
What is the best course of action? I have currently installed hg 2.4 and I have already created a local repository, which I am handling via the command line.
It is possible that I missed the relevant information online: please point it out to me if that is the case.
The best course of action is to just keep things as they are. According to Mercurial 2.4's upgrade notes, only bookmark handling has been incompatibly changed since 2.3. So, the repositories should still be compatible between versions.
In future upgrades, you'd better wait for TortoiseHg to catch on the latest release of Mercurial. Unless you need a security update or a critical fix, there are few reasons to upgrade so diligently. Moreover, if you use the GUI regularly, there's even less need to upgrade Mercurial separately.
The Mercurial crew is extremely diligent about being backward compatible; Take a look at the release notes to see if there's anything in 2.4 that might make a difference for a Mercurial 2.3.x client to a 2.4 repository. The TortoiseHg crew has been quite good about keeping up with newer releases of Mercurial, so you won't have to wait too long to see a new release of TortoiseHg based on Mercurial 2.4.

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:
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.
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!
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.

TortoiseHG and Google Code

I have been using TortoiseSVN for some time and I really like it. I was told TortoiseHg was worth checking out and "much better than SVN" so I am trying to get started with it.
I created a google code repository and I managed to upload one folder to it. However, when uploading another folder, I keep getting the error "abort: repository is unrelated"
TortoiseHg and TortoiseSVN are not really comparable critters, as they are just GUI front-ends for two completely different version control systems. SVN is an older centralized stalwart, and Hg is a newer distributed system. Whether you should use SVN or Hg really depends on your use case, specifically:
if your developers will ever be cut off from the central repository. Using Google Code would indicate 'no' since all developers need is a network connection, but off-network developers would still be a problem. Being a DVCS, Mercurial would allow off-network developers to work anywhere, only having to be on network to deal with server push/pull situations.
if your developers care about file locking. SVN has built-in file locking and Mercurial does not.
if your developers struggle with merging. Mercurial has a more developed merge capability and handles conflicts more intelligently.
If you end up with three no's, then SVN may be the one for you.

Can we use different versions of Mercurial/TortoiseHg to work with the same central repository?

Is there a risk of damaging the repository (using a file share) if we use different versions or the tools to pull from and push to the central repository?
FYI: The central repository was created with Mercurial 1.5. We are planning to upgrade our tools to Mercurial 1.8 with Tortoise 2.0.
What you're describing is safe to do. Every version of Mercurial can safely read and write repositories created by older versions. Older clients will refuse to read/write repositories that are too new for them.
So as long as you're accessing repos created with 1.5 you can do so with 1.8 just great.
More detail: https://www.mercurial-scm.org/wiki/RequiresFile