Mercurial Best Practices - Branch on Feature/Task?

Question

I just switched to Mercurial from SVN. I've done some basic stuff (importing my code, making commits, getting the hang of log/commit/revert/etc.) and read some tutorials on branching/merging.

My question now is: What's the best ("Mercurial") way to use Mercurial?" I don't want to follow SVN paradigms; I want to do things the "right" way.

I should mention that I'm a sole developer on most of my projects, and I'm using agile/scrum practices. Maybe my question should really be should I be cloning/branching per feature? Per task? I remember reading that this should be the case for Git, and this allows you to essentially keep multiple copies working at the same time and separate features vs. bug-fixes vs. whatever (i.e. keep your working copy separate for each different thing that you're doing). And it's also apparently part of Mercurial's best practices.

Or I could just keep one copy, make my changes, and commit prolifically. Whatever.

If this question is too subjective, I don't mind closing it, provided someone can link me to some reading materials on how to use Mercurial best. That's what I'm after.

Answer 1

Speaking as a (mostly) solo developer, I think my answer is ... yes. When I know I'm making a quick change I do it in my "main" development directory, but if I have any doubt about how long/complicated something will be, I branch right at the beginning. The nice thing is that you can really do it in any way (and in any order) that works for you. If you are working in your main dev directory on a longish mod and someone comes in and needs a quick fix now, just clone trunk, fix it, check it in, and Bob's your uncle!

I look back on my days with SCCS/RCS/CVS with sadness.

I am about to lead 3 designers into the Promised Land. They are old-school and have been using Dreamweaver in shared directories (the horror!) for years. This weekend we are moving them to a world of XAMPP, TortiseHG, rsync, and deve/staging/production.

Update: I phrased my answer in a highly ambiguous way. Thanks for calling me on it, Michael E.

My "main development directory" is actually a clone of production-master. When I say "branch" I mean that I'm going to be working at something for a while, often for several days to a month or more, but it's still a clone of "something." I know that sounds vague, but sometimes I'm working with other developers and we are passing stuff back and forth and we just don't worry too much about the merge to trunk until it's time to go to staging. (And even then it's often pretty painless.)

So a "quick fix" for me means updating my "main" dev dir to trunk, hacking, testing, push to staging on the main machine (and test), and then push to production (and test). Most of the time quick fixes are done as an anonymous branch.

BTW, cloning against a local repository is so fast there's no reason (in my mind) to do anything else. I have one medium-ish project with something over 7,000 files and about 4 years of near-daily commits from 4 developers -- the repository is about 200MB. Clone time (on an old-and-slow machine in my garage) is 10 seconds. I keep an local clone of the remote production master and do hourly fetch'es with cron. HTH.