Mercurial Best Practices - Branch on Feature/Task?

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 rea开发者_开发技巧d 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.

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.

Basic guide: https://www.mercurial-scm.org/guide/

A guide on branching: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

I prefer shelving for quick fixes, anonymous branches for two-to-three changeset changes, and cloning for anything bigger than that.

Follow this link. http://hginit.com/

Joel Spolsky clearly explains the difference between legacy centralized VCS and a DVCS.

He also guides you through the steps to get acquainted to the mercurial workflow, coming from the subversion background.

I have found named branches to be preferable to cloning for a couple of cases. If have project settings that are not checked into source control them cloning requires me to copy these settings around to all of my clones. Most of my work is in Django where having a local_settings.py not in source control is a common idiom. Also I find that sharing clones is not as easy as sharing named branches. If I'm the only developer working on a feature then cloning is fine. The second I need someone to help me on a feature a named branch would have been the better choice.

@k3b mentioned gitflow and there is a hg plugin in development to do the same thing in hg which uses named branches. https://bitbucket.org/yinwm/hgflow/wiki/Home

No. Instead of a branch i would clone the working directory/repository for a feature branch.

I am following the excelent descrition in a-successful-git-branching-model.

Note the referenced article is for git not for hg. However the branching model is universal just the syntax between git and hg differ.

[update 2013-01-31] Thanks @Alex for your comment . i was not aware of the differences between hg and git. Is there somebody out there with hg experience that can verify that the git branching modell is applicable to hg or needs modificatoins to work with hg (excpet the commandline syntax)?