3

Update: We ended up using a process very much like this schema (thanks to neuro for the link). We massaged out repository into a state where default is stable (and has the same code as our production environment), we have a dev branch, feature branches for new stuff and use release branches for releases. All seems to be working perfectly.

Backstory

Our team has recently switched from using SVN (using ToroiseSVN Windows client) to Mercurial (using TortoiseHg Windows client) for version control. We have successfully exported our SVN repository and imported it into a Mercurial repository.

We now have a Mercurial repository where we can see the entire history of revisions (changesets in Mercurial).

How we did it in the old days

Life was simpler in the old days; our development process was not really multi-stream like it is now. The trunk was used to hold all code - even changes that were still in-flight (as long as it didn't break the trunk). When it came to managing releases with SVN, we would checkout the trunk (which holds all code), revert the individual changes we didn't want as part of the release, and create a tag for it.

Cherrypicking the code we want with SVN was easy. Bug-fixing previous releases and ensuring it was part of the trunk was simple too.

What we are doing now

In Mercurial, we need to be able to get a snapshot of the "trunk" (default in Mercurial) with individual changes reverted out. We can do this using hg revert.

To snapshot this, we have created a "named branch" - let's call it Build-4.0.1 for now.

Where the challenge arises

Development continues on default as normal when a bug is found in Build-4.0.1. Let's assume the bug is in one of the reverted files. We change the code from the branch for Build-4.0.1, create a new "named branch" (Build-4.0.2) and want to merge it back into default without pushing the reverted code over the top of newer code. How can we accomplish this?

Alternatively, is there a better workflow for managing the releases and our code in Mercurial? I quite like the look of this wonderful SO answer on managing release branches, although I am not sure how we can transition to it from the state we are in now (with in-flight stuff in default).

Note: I have looked at the Transplant extension, but haven't used it yet - could it be part of the solution to this challenge?

Community
  • 1
  • 1
adpd
  • 211
  • 1
  • 3
  • 8
  • The way you're using Mercurial does not make sense, the answers below provide you with good information how you SHOULD use mercurial. Yes this means learning new development methodologies but a DVCS is radically different from a CVS, and coming to terms with that as soon as possible is a key to reaping success with a DVCS. Congratulations on you abandoning a CVS and taking advantage of a DVCS, your development story will become substantially more expressive adhering to sensible branching strategies with Mercurial. – Chris Marisic Dec 02 '11 at 16:22
  • Chris, I totally agree with the statement about the way we currently use Mercurial is not sensible; hence the reaching out to find better ways. The "schema" that neuro links to is the approach we are currently experimenting with - it seems to meet all of our needs in theory. – adpd Dec 05 '11 at 13:35

2 Answers2

4

Well, to begin with, your use of revert seems strange to me. Usually it is used to revert modifications done to the working copy back to the version of the repository.

The usual way to get the working copy to some point backward is to update :

hg update -r 1234

from there, you can tag, modify, commit, etc.

To merge back you only have to merge your release branch to the default branch. It will work like a charm, unless it is to different/old a release.

Transplant works fine, but do something a bit different from merge : it take your changeset as a "diff" and apply it as a new modification.

To manage your releases, you can look this other answer (by me) :

How to use mercurial for release management?

What we use is a clone / main branch that holds the most stable version, which is released at some points. On this clone : branch, we can fix critical bugs (hotfix). In parallel, we use a dev clone / branch to develop. The hotfixes are merge as soon as completed from stable to dev. When the current development is done, we merge the dev on stable / default.

This schema is pretty good to understand things :)

Good luck !

Community
  • 1
  • 1
neuro
  • 14,948
  • 3
  • 36
  • 59
  • http://stackoverflow.com/questions/2506803/difference-between-revert-and-update-in-mercurial might be worth a look too – jk. Dec 02 '11 at 13:36
  • Love the article you linked to (http://nvie.com/posts/a-successful-git-branching-model/). – adpd Dec 05 '11 at 13:36
  • @adpd: Yes, the process is not that original, but the scheme/image is worth a thousand words :) Enjoy Mercurial ! – neuro Dec 06 '11 at 10:13
3

Going through all the changes and taking out the ones you don't want is not a common way of creating a release, to put it mildly. The Common Branching Patterns section in the SVN book suggest some more popular work flows:

  • release branches: create release branch from unstable trunk, fix bugs to stabilize it, cherry pick bug fixes between them while the branch is in maintenance mode.
  • feature branches: keep the trunk stable and ready for release by only merging in the feature branches that you want

The second one is probably the best fit here, because it gives you a place to put experimental or risky changes until you feel confident about them - these are the changes you would have reverted before a release in your old workflow.

Both of these branching patterns should carry over just fine to mercurial. In case you go for the first approach, note that mercurial (since 2.0) now has a graft command, you no longer need the transplant extension.

Wim Coenen
  • 66,094
  • 13
  • 157
  • 251