0

Ok, I have tried searching for something concrete, but haven't come up with anything.

If I am working away on new features in my default branch and a bug report comes in from previous work, what is the best way to handle the fix and pushing? I was trying Bookmarks, but then I saw that it also pushes ancestors. This is what I was doing...

  • Work on default branch for future changeset (rev 76)
  • Switch to bug fix in middle of coding
  • hg bookmark main (for current work)
  • hg bookmark -r 76 fix1 (for bug work)
  • hg update fix1
  • hack hack on now rev 77
  • hg commit -m 'bug fix'
  • hg update main
  • hg push -B fix1

And that's when I noticed that 76 also went up.

Since I don't want new unfinished work going up, just the bug fix, what would be the best way to approach this? Clones for bugs?

Thanks.

dbinott
  • 911
  • 1
  • 11
  • 36
  • Use branches... or clones... and clean-up description of you workflow - you work on " in default branch", yes? And must to switch to bugfixing in the middle of coding, yes? – Lazy Badger Oct 17 '12 at 18:30

1 Answers1

1

You were setting your fix1 bookmark on the same changeset as the main bookmark instead of first updating to the desired changeset where to fix the bug. And when pushing, you can define the revisions to be pushed with the -r parameter. This will only push the branch and ancestors of the specified revision (the branch with your fixes in this case).

Try something like:

  • Work on default branch for future changeset (rev 76)
  • Switch to bug fix in middle of coding. Bug is in Changeset 50
  • hg bookmark main
  • hg update -r 50
  • hg bookmark fix1
  • hack hack on now rev 77 to fix bug
  • hg commit -m 'bug fix part 1'
  • hack hack on now rev 78 to fix bug
  • hg commit -m 'bug fix part 2'
  • hg push -rfix1
  • hg update main
  • Bring your bugfix in the main line of code again
  • hg merge fix1
  • Delete the bookmark if you want
  • hg bookmark -d fix1
  • work on your new feature again
James
  • 11,654
  • 6
  • 52
  • 81
  • This is known as a `daggy' fix because it takes advantages of the DAG (directed acyclic graph) relationship that the changesets have to each other. More at http://mercurial.selenic.com/wiki/DaggyFixes -- also, you don't have to locate the exact changeset where the bug was introduced. You could just implement a fix on top of a changeset where you know the bug was present, e.g. v1.0. – Yawar Apr 21 '13 at 09:18