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.
Related
We've recently moved our codebase from subversion to mercurial, and are doing our first release to production from the mercurial codebase this weekend.
We have a three repo setup, let's call them dev, stable and release, where dev is a clone of stable and stable is a clone of release. At the moment, dev has our version 7 code, and stable has our version 6 code. We've just pushed the version 6 code to release. Our next release, version 6.1, is scheduled for next week.
The problem is that, since we're also doing a major upgrade in the v6 release, we're expecting to release multiple times (6.0.1, 6.0.2, etc) before the 6.1 release. Going forward this won't be a problem as all three repos will have different version numbers, but right now both stable and release are v6.
If I change the version numbers in our poms on stable to 6.1, this change will have to be pulled back to dev, which will mean fixing it there before any of those artefacts can build (so as to not pollute the v6.1 release with what are really v7 artefacts).
Is there a way to tell mercurial to pull this change into dev without actually accepting the change, similar to what svn's merge --record-only does? Is the only option to pull the change to dev and then do a backout?
Thanks
I can't say I follow your version-management logic; what do different version numbers have to do with which changes you pull or merge? But if I understand you correctly, you want to modify the explicit version number in the stable branch (say, to 6.1), then continue pushing changes to dev but prevent the version number of dev from becoming 6.1.
Here's how you do it: Make sure the version number is in its own changeset-- you don't want it sharing a changeset with changes that you do wish to apply. Now merge this changeset, telling mercurial to always use the "local" version of a file during the merge by means of a special "merge tool":
hg merge --tool internal:local -r REV
As hg help merge-tools explains:
A merge tool combines two different versions of a file into a merged file.
...
"internal:local"
Uses the local version of files as the merged version.
See the full help for the details.
Merging revision REV will also merge any changesets that REV depends on. So you should first merge the revision immediately before REV (in the normal way), if necessary. This could be automated with
hg merge -r 'parents(REV)'
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’m new to mercurial, about 2 months now. We are using it on a new project and tried to create a new repo, a clone of the trunk, to be used as release “branch”.
We use a central repo, everyone is pulling/pushing to/from it over https using hgwebdir.cgi. Using on server hg 1.5.4 and “clients” various versions, 1.5.2 -> 1.6.3
Everything thing was ok. The clone was good (hg verify after clone), the only problem is that very soon this repo got corrupted (empty or missing ; in manifests not found).
The main repo is ok, only this release get broken very soon.
The names of the repos are (folder names and published names, all reside in the same root folder):
A.B – for the trunk
A.B.Release – for the release repo
(read something in the docs, which sounded like this might be a issue – see
One other very strange thing is that checkins made only to trunk (A.B) are seen as available on the release branch, and they are displayed as errors on verify ( in manifests not found). Don’t understand how these got there.
Any clues?
It's not an answer, but I'll state that what you're doing is definitely supposed to work. Making sure the wire-protocol has full backwards compatibility is very important to the Mercurial folks.
The "cross-talk" between your two repos is very concerning and shouldn't happen unless someone erroniously used the share extension.
What if you try creating the A.B.Release clone by using clone --pull rather than clone by itself?
I'm forced to use Visual Source Safe 2005 at work. I'd like to combine that with a DVCS, so that I can check in files locally without disrupting my co-workers if there's a bug or it doesn't compile.
In my attempts with Mercurial, it works, but causes a few weird issues. Namely, it thinks someone else has checked out the files I have checked out.
Here's my thoughts on how I should manage it:
Disable auto-checkout.
Work locally in Mercurial
When I'm ready to push my changes...
Clone my Mercurial repository.
Update my Visual Source Safe repository
Pull and merge the two repositories using Mercurial.
Check everything into Visual Source Safe.
Does this sound reasonable? I'm always hearing bad things about VSS, is this just asking for me to see those problems firsthand?
WBlasko
I've found the same problem. I wanted to change files and merge them when needed instead of waiting for some other developer to unlock it. The solution that worked for me was:
1) Get the latest version of a VSS project (I placed all VSS projects under vss):
c:\vss\projectA
2A) Initialize with Mercurial
cd vss\projectA
C:\vss\projectA>hg init
2B) Clone the project to the place where it could be changed at will
hg clone vss\projectA myProjects\projectA
3) Grab the latest changes from the VSS copy (skip if you came from 1 and 2)
C:\myProjects\projectA>hg pull
C:\myProjects\projectA>hg update
(solve conflicts if any)
4) Work at will with the cloned version. Later, push your work to the vss copy:
C:\myProjects\projectA>hg push
(don't run hg update yet, wait for VSS latestes version)
5) Now, perform a checkout of all files to the VSS project
6) Run "hg update" on the VSS project to merge your changes to the latest VSS changes.
C:\vss\projectA>hg update
(if there are conflicts, resolve them)
7) Commit the changes
C:\vss\projectA>hg commit
8) Perform a VSS checkin (releasing the locks to the other folks)
Go back to step 3. repeat steps 3-8 forever then... ;-)
This way you can work with a good version control system while still being able "talk" to legacy projects. You will be also be able to enjoy:
a) No problem with locked files
b) you can share your repository with others that know how to use Hg
c) make branches , etc
Just be carefull to first update/solve conflicts, test and then perform VSS checkin
Cheers,
Luis
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