views:

674

answers:

2

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.

+3  A: 

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

http://mercurial.selenic.com/wiki/Branch

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).

Jon
+6  A: 

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.
las3rjock
las3jrock: Thanks. Why do you recommend branches for features rather than for the improvements within a feature?
uzo
I recommending branches for features rather than for the individual improvements that constitute each feature because that makes branches an intermediate level of abstraction between the repository (which contains the entire revision history of the project) and individual commits (which are the atomic units of the revision history). In this workflow, related commits are grouped together in branches. In the workflow that Jon describes, it seems that each branch contains exactly one commit, in which case branches and commits are redundant representations of the same unit of the revision history.
las3rjock
No no, I didn't intend to imply that you would use a branch for one commit - that would be ludicrous : ). It was just meant to designate a unit of work - an improvement could be the addition of a new field to a web form, or a bug fix, or a major project in itself, it's up to you to determine the granularity at which you want to work...
Jon
@Jon: I was pretty sure that was not what you meant, but that was how it read in the context of the original question. I think we agree that branches should exist at some level of granularity between the repository level and the commit level, and that the exact level of granularity is for the user to decide. ;-)
las3rjock