1

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

rjohnston
  • 7,153
  • 8
  • 30
  • 37
  • When I say it won't be a problem in the future I mean we can make these point releases without making version number changes in the codebase, since the version numbers in the codebase are different – rjohnston May 17 '13 at 00:29

1 Answers1

2

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)'
alexis
  • 48,685
  • 16
  • 101
  • 161
  • Thanks for the answer. Like I said, this is not how we normally manage version numbers or releases, it's a one-off due to transitioning to mercurial and the huge upgrade happening in this release. – rjohnston May 18 '13 at 10:31