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
Related
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.
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.
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.
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.
I have a set of mercurial repositories being served online with hgwebdir.cgi. I would like to be able to show a graphical representation of the branches and merges in the same way that this site does. I can't seem to find any reference to how to do that though. Does the functionality only exist in hgweb and not hgwebdir?
This future will be enabled in next release, try use develop version from repo.
In console u can use glog extension
Until version 1.1 comes out (in a few days) you'd need to clone and install from the Mercurial crew respository