Question

Hello, I know Kiln uses "branch repositories" for branching which is actually full-fledged repositories. And I've found a lot of explanations why it is better than native Mercurial branches in most of cases. But are there any advantages in using native Mercurial branches?

Answer 1

Yes, there are. I think, Mercurial native branches have several advantages.

Two insignificant (in my opinion): If you use "branch repositories" ...

1. ... and you made changes to several branches on your local machine, you have to push each branch to your "main" repository (the same things for pull operations). If you use native branches you have to do only one push operation.
2. ... since your branches are actually different repositories (therefore, different directories), it can breaks you environment settings (e.g. IDE settings, relative paths, etc.), when you switch between branches during your work. But you can rename repositories (i.e. directories which contain repositories), instead of change your environment settings every time (Joel explains this technique in his tutorial)

And one significant advantage (also in my opinion):

1. If you use "branch repositories" it's really hard to manage branches, since they are located in different and non-connected places. You have to do it manually. But this is exactly the thing, that Kiln does best! Kiln does all boring stuff for you and provides natural UI to manage your branches and repositories. (Please, look at this post for more information)

And as you've noticed "branch repositories" have a lot of advantages.

Answer 2

This is similar to this question: http://kiln.stackexchange.com/questions/592/why-are-branched-repositories-preferred-over-named-branches-in-mercurial

The most significant benefit to native branches, for our process, is that it makes a branch-per-feature development model practical. It is technically possible to do this with the branched repository approach, but you eventually end up with 1000 repositories, which I don't think anyone would recommend.

To illustrate the problem, let's say you check in features A, B and C into the default branch. At that point, you find a bug in feature A that cannot be pushed into production. You must then fix the bug in feature A before you can push the working features B and C into production. When the fix is hard and the demand for B and C is high, this can result in a fair bit of stress. (This was my life with SVN.) This problem seems to scale exponentially with the number of developers.

Alternatively, let's say you check in features A, B and C into branches A, B and C, respectively. Now, when you find the catastrophic bug in feature A, you can simply ignore it, merge B and C into your primary/default branch, and push the default branch into production. You may then fix A at your leisure.

Some teams may not need that workflow, but for those of us who do, named branches appear to be the only workable option.