Questions about branching in Mercurial

[Mark A. Flacy]

On 2007.05.05 09:40, Tim Allen wrote:
> My employer currently uses CVS internally for all its version-control
> needs, and we're now sufficiently annoyed that we're looking for
> a replacement. For the record, our CVS repository is similar to the
> Linux Kernel in terms of number of files and number of change sets,
> however it currently has about 150 branches and nearly 6000 tags.
> 
> The branching model we'd like to use runs something like this:
> 
>  - The trunk contains the latest stable version, usually whatever is in
>    production plus any low-risk bugfixes or well-tested and complete
>    features (that is, it should be safe to package this branch up and
>    roll it out to production at any time).
>  - Every time we need to patch production and the trunk is not fit to be
>    rolled out (say, if there's complete and stable features we don't
>    want to release yet), we branch from the last stable version, apply
>    the patch to the branch, and roll it out. These maintenance branches
>    should be stored centrally so that when a new patch needs to be
>    rolled out, you don't have to figure out who made the last patch six
>    months ago so you can pull from their repository.
>  - Development is to be done in separate branches until stable, when
>    they can be merged into the trunk.
> 
> Because of various bad experiences with CVS and developers messing
> around with repositories on the server, I've been avoiding version
> control systems whose solution to centrally-stored branches is
> 'developers should ssh to the server and clone off a new branch there'.
> Hence, I've been concentrating on Mercurial's "named branches" which it
> seems can be administered nicely with "hg push" and "hg pull".
> Unfortunately, named branches aren't documented very well in "hg help",
> and the wiki page isn't much better.

Why do you think that named branches are a better solution than a cloned repository?