Question

Named branches are an important feature for us.

The problem is that pushes with new named branches appear to require the force option when initiated from the client tools. When initiated from the server, they simply fail, presumably because the force option is not enabled.

Main question--> How about offering to attempt a forced push if the initial push fails?

An aside on named-branches before I start a religious debate:

• Named branches are the most important reason for our move from SVN to a DVCS.
• In particular we need to move to a branch-per-feature development model.
• With our repository approaching 1Gb, creating a "branch repository" takes about 90 seconds.
• In what way can a complete repository copy be considered a lightweight branch, anyway?
• Named branches provide a concise way to track unmerged features. How do we do that with 30 branched repositories? Check each one individually, every time?

Answer 1

We actually discourage using Mercurial's named branches, especially for new users, as it can impact normal usage patterns in odd ways (such as your force-push-by-default problem).

I have opened a feature request to make an extension that offers to force a push if the initial push fails. Just to be honest, we are unlikely to enable this extension by default; most users are going to get that error when they've forgotten to run hg pull and hg merge prior to pushing, and the Mercurial team has already discovered from testing that, as-is, new users still ignore what the message is telling them and simply run hg push -f more often than we'd like. In the meantime, though, since it appears that you always want to force push, you can just add these lines to your .hgrc/Mercurial.ini file:

[alias]
push = push -f

at which point hg push will always create new remote heads when necessary.

We do not consider branch repositories to be lightweight--they are full, independent clones--but they should not be slow. Making a branch of a 1.5 GB repository in my Kiln On Demand account takes 7 seconds; if it's taking 90 seconds for you, we'd really like more details, because that's a bug we'd really like to fix.

That said, you're correct that branch repositories are not meant to be used in a branch-per-mini-feature manner. They're meant to be used for developer sandboxes and longer-running communal branch work. For example, at Fog Creek, most developers have personal branch repositories off the main central repository that we check into when we're doing something more substantial than a tiny bug fix. Then, on the client, rather than having a checkout for each branch/central repo, we might just have a push alias in the repository's .hg/hgrc file. For example, my FogBugz clone currently has the following in its .hg/hgrc:

[paths]
default = http://ourkiln/Repo/FogBugz/Group/7-2
benjamin = http://ourkiln/Repo/FogBugz/Group/benjamin

In this case, for normal, bug-fix work, I can just run hg push and send it right to the central repository. When I know I'm doing something more long-winded that's going to need to be reviewed, I can instead run hg push benjamin.

To monitor everything going on, you can use Kiln's Activity Feed, which lets you filter by project, by repo, by user, or by a combination of those. You can subscribe to the activity feed via RSS. This makes it very easy to see all activity going on in a project. Even if you use Mercurial named branches, the activity feed may prove useful as a way for monitoring the entire state of a project across otherwise-unrelated repositories.

Answer 2

This is a rather involved question with a few different parts, so I'll try to break them out as best I can.

The problem is that pushes with new named branches appear to require the force option when initiated from the client tools.

This is the default behavior of all Mercurial repositories. You can test it by making two local clones of a repo on your machine, adding a new branch to one, committing, and pushing that change to the other. You'll be greeted with the same abort: push creates new remote branch 'foobar'! (did you forget to merge? use push -f to force) message.

When initiated from the server, they simply fail, presumably because the force option is not enabled.

You are correct there. We currently don't allow pushing of additional heads (multiple heads is fine, just as long as both repos have them) from the web interface. Ben's answer gets into why we chose to do that, so I won't repeat that here.

Your question has started some discussion internally, to the point we're considering your suggestion of allowing pushing on the web with an extra confirmation step. As we're close to releasing, it definitely won't be in 1.0, but may make it in shortly after that.

Like Ben said, we generally don't use named branches here at Fog Creek because we find the Mercurial branch workflow to be a little confusing and doesn't really take advantage of the benefits of DVCS as well as separate repos. In a way, named branches are not unlike Subversion's method of branching -- there's nothing really distributed about that workflow. With branch repositories, you can do your work in parallel, merge, push, and pull when you see fit, all without interfering with other developers.

All that said, Mercurial is making some changes that might make Git-style branching easier in the future, which may make this type of workflow more appealing. We have what we think are best practices, and to a certain extent we want Kiln to help enforce those best-practices, but we do also want to consider reasonable alternatives, so this type of discussion is good.