CODEWITHSUNDEEP
netbeansmercurialworkflow
uzo
uzo

Reputation: 2821

Please suggest a better workflow in Mercurial

I'm new to Mercurial and what I'm starting to realize is that my basic workflow may not be the most efficient way of working because I perform commits so frequently and for feature improvements that are so small that when I need to find some earlier step to revert to, it is extremely difficult.

Here's what I do after I have a project set up in Mercurial and have already completed my first commit.

  1. Make some changes to a file and get it to a state where a small improvement is working
  2. hg commit -m "improvement A works"
  3. Make some changes to the same file and get it to a state where the next minor improvement is working.
  4. hg commit -m "improvement B works"
  5. Check whether all of the minor improvements add up to a single minor feature working correctly.
  6. hg commit -m "feature A works"

If I find a mistake that was made in "improvement A", I open up history (with the Netbeans Mercurial visual plugin) and copy and paste some of the code back into my current version and start again from there.

This doesn't seem like a good system - I would appreciate any suggestions.

Upvotes: 5

Views: 1717

Answers (3)

Jonathan Holloway
Jonathan Holloway

Reputation: 63734

You could isolate the changes for the improvements into branches maintaining a stable trunk.
Take a look at Branch wiki page.

Workflow pattern would be:

  1. Create branch for improvement A
  2. Complete work for improvement A and checkin
  3. Test changes and merge back into trunk if successful
  4. Create branch for improvement B
  5. Complete work for improvement B and checkin
  6. Test changes and merge back into trunk if successful

If you find a mistake you can abandon the branch (or correct the bug in the branch prior to merging back into trunk).

Upvotes: 7

thethinman
thethinman

Reputation: 332

I disagree with the branches approach. If no parallel development is needed, why add the complexity of branches? There's nothing wrong with small 'checkpoint' commits. Tags can be used to point to important commits, which might be more clear.

Upvotes: 4

las3rjock
las3rjock

Reputation: 8724

I agree with Jon that branches are the solution, but I would create branches for features rather than for the individual improvements that make up a feature. The workflow pattern would then be this:

  1. Create branch for feature A.
  2. Complete work for improvement A and commit.
  3. Complete work for improvement B and commit.
  4. When the feature seems to be working, merge the feature A branch back into trunk.

If you find a mistake in an improvement A of feature A, instead of starting over, you switch to the feature A branch and do the following:

  1. Fix improvement A and commit.
  2. Merge the feature A branch back into trunk.

Upvotes: 10

Related Questions