Mercurial TortoiseHG - How to align updates between branches?

Question

Considering a project in TortoiseHG with 3 branches ("default", "Phase 1", "Phase 2"), is it possible to make changes to one branch and make them reflect in one or both of other ones, without merging them?

The idea is to correct a bug in one branch and not have to "update" to each of the other branches to correct the same bug there.

If so, how is it done? Is it synchronization? Push? Something else?

Could someone tell me what the steps are to make this happen (assuming it is doable)?

Thanks Setnara

Answer 1

Yes, it's possible and I see at least 2 obvious and one nice solutions, but

NEVER USE OBVIOUS IN FUTURE AND FIX BRAINLESS WORKFLOW ASAP! IT'S NIGHTMARE TO HANDLE SUCH PROJECTS FROM CODE-MONKEYS LATER!!!

---

Rebase-style

• Rebase changesets (hg help rebase), starting from first changeset of bugfix, into new targets (Heads of branches) hg rebase -s $BUGFIX_START -d Phase 1 + hg rebase -s $BUGFIX_START -d Phase 2 (in assumption that bugfix is part of default branch), keeping rebased changesets in original branch hg rebase ... --keep
• Resolve possible conflicts
• Because rebase will rebase all descendants of $BUGFIX_START, with probably some changesets unrelated to bugfix, hg strip not-bugfix changesets from rebase-destinations

Graft-style

• Graft (hg help graft) allow inject individual changesets from one part of tree into another (contrary to rebase, which inject subtree from custom node or merge, which inject all history from greatest common ancestor). You have to:
  • update to destination branch (hg up Phase 1), read hg help update
  • select all needed changesets and enumerate in rebase (see -r options of command) hg graft -r $BUGFIX_START -r $BUGFIX2 ... -r $BUGFIXN -D -U --log
  • perform two previous steps with Phase 2 branch

and, at last

"The Right Way" (tm) - Named Branching

• Create named branch from the point or parent for $BUGFIX_START hg up $BUGFIX_START + change something + hg branch SEMANTICNAMEOFBUGFIX``hg ci -m "Branch for $BUGFIX"
• Rebase (with stripping after, if needed, and without --keep) bugfix-related changesets into this new named branch
• Merge SEMANTICNAMEOFBUGFIX into default, Phase 1, Phase 2
• Always use "Branch Per Task" in future, stop spaghetti-bullshit in code and repository-histories

---

I translate a beam of contempt to your mentor: He had to tell and explain it before authorizing public commits (local personal repository can be a nightmare to any extent)

I highly recommend reading not only the code, but the documentation and advices and hints from wise and experienced users, in order do not constantly reinvent the wheel

Answer 2

This is not possible, per se. Merging is always a one step process, due to the potential conflicts you can have. They need to be handled separately, one at a time.

Of course, there is the possibility to have multiple clones already updated on each branch, if the update is painful. That way you can go through them to merge the new fix branch...

However, this is a typical problem, that your release process can help solve. For instance, if default is your source branch and Phase1 and Phase2 are to be merged back eventually in default, why not have default merged frequently in all other branches? Instate a policy to merge default often in development branches, it will help solve conflicts sooner than later, and they will benefit from the occasional bug fix, after it has been merged in default.

If default is not your source branch, create a new branch that can hold only the fixes, and merge often this branch in your phase branches, but you get the gist.