4

I've read similar posts of SO, the official Hg guide, many articles and guides, and it's still unclear to me what the best Hg workflow is for developing by feature. Maybe some of the articles on the web are years old and don't include the latest features from Hg. Obviously there's also a lot of options in how to approach it.

I'm a solo developer working on a project where a request for a fix or feature will be submitted to me as a task, like "Task #546 - Change whatever". Some of these tasks take a few days, and some tasks are open for months and there's often up to a dozen going at one time. A task is shipped to the final site after it's approved by the requestor.

The Hg guide seems to recommend having a clone per feature. But having a dozen full copies of the site on my drive seems... wasteful? I'm up for trying it, but I've seen other suggestions that make more sense. Do people really have a dozen copies of each site on their dev machine at a time?

Name branches at first sound like what I'd want, where's I'd name a branch "task 546" work on it, then merge it back in when it ships. I see a lot of discussion about the permanence of the names and having so many branches (though they can be closed). Some people seem to care about that and some don't. I don't know Hg enough to know if I care or not, and what the downsides really mean.

Finally, bookmarks seem to be popular with the more recent articles and it would seem that the best way to use them would be to set a bookmark like "task 546" then when you merge it back into the main branch using a commit message that has the task number in it to keep a reference to what was being done in the work. I know you can delete bookmarks, but it's unclear if I'd need to do this after the final merge.

So my thought for a combined approach is to have:

one repo

three named branches:

  • "default" which holds the released version of the site
  • "dev" on which I do feature development
  • "test" which would hold all of the tasks being reviewed by the client

on the "dev" branch I would use bookmarks for each of the tasks that I'm working on, so I'd have a head for each task

My workflow for a task/feature would be to:

  1. Update to the main line of the "dev" named branch
  2. Start a new branch using a bookmark for the task "task #123"
  3. Commit changes until I'm ready for the client to review
  4. Merge "task #123" into the "test" branch
  5. Deploy "test" to the test server
  6. Repeat the commit, merge, deploy until ready for production
  7. When approved, merge with the main line of the "dev" branch with a commit message that includes the task name
  8. Merge "dev" into the "default" branch.
  9. Deploy the "default" branch to the live server
  10. Merge "default" into the open feature branches

Thoughts? Would I be better off just having a clone for each feature, and a "live" and "test" repo that I push to?

Edit: I see from some links that I should be doing the development off of "default" so my first change to my listed process would be to use a name "production" branch instead of a named "dev" branch.

Jeff S
  • 554
  • 5
  • 13
  • Since you ask "would I be better off ...", then it implies that there is some way to quantify how good one solution is over another. Does the solution you have proposed work? Yes it does. Will it scale? According to [this](http://stackoverflow.com/a/9170497/267), yes. – Lasse V. Karlsen Jun 29 '13 at 18:07
  • One way to quantify if one solution is better than another is to go through all the things you need to ensure that your code is persistent, good, etc. If you have a dozen branches locally, it will be easy to work with a specific task at any one time, since you will have to manually pick the right folder (clone) to work with. However, can you ensure all of those clones survive a disk crash? On the other hand, if you use normal branches, or bookmarks (synced to the central repo), even if your machine is stolen, lost, or completely hosed, you will still everything. I would use branches/bookmarks. – Lasse V. Karlsen Jun 29 '13 at 18:09
  • @LasseV.Karlsen , for me "better off" is a mix of 1) is my code safe and easy to work with, 2) is the process efficient and minimally prone to errors in following it. Mostly I'm sure that what I'm trying to do is fairly common, and that others work in the same way and may have tried a couple workflow approaches and have some feedback on what has worked the best for them. – Jeff S Jun 29 '13 at 18:23
  • Personally I try to avoid having open work because that usually means the work is poorly defined to begin with. In other words, I try to avoid having several large(-ish) open cases at the same time. If, on the other hand, you make sure you merge the default/dev main branches into your task branches regulary, to avoid getting big merge problems at the end, it shouldn't pose any problems for you. – Lasse V. Karlsen Jun 29 '13 at 18:33
  • It's not my preference either, but it happens a lot with this client. I probably have 15 tasks just waiting for final approval. For my own and other small project I'll just use simple branching. – Jeff S Jun 29 '13 at 19:04

2 Answers2

3

Bookmarks-style of branching (Git-like "branches") works poorly in, at least, two common cases

  1. Cross-tasks merges in the process of development
  2. Time-back machine, when you'll want to see "the whole history of changes for task#123" (you can do it visually and, with some grimaces and jumping, using revsets)

While using named branches haven't such problems and, btw, workflow with named branches (and only default branch as aggregation point) will be less complex and more logical way

  • Default contain only mergesets from task-branches, head of default is always "stable version"
  • Heads of named branches are WIP; branches, merged to default - finished (and accepted by customer - see below) work
  • Default, merged to task-branch (after development of task, before merging task-branch to default) is equivalent of your "test": without affecting mainline you can test final state of feature, integrated into your stable app, show results to customer
  • Accepted work added to stable mainline by merging named branch to default
  • History (full history) of changes for every task in the past can be easy restored by using single, easy, short, memorable revset for log: -r "branch(TASK-ID)"
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • It sounds like the history would be the bigger benefit of named branches. I think I'd still need a "test" branch because the client might be reviewing multiple tasks at the same time and with using the heads to test I'd have to set up a test website for every feature. – Jeff S Jul 01 '13 at 02:40
1

I like it. +1. This is the way I'd do it.

Aaron Jensen
  • 25,861
  • 15
  • 82
  • 91