Using named branches (`hg branch`) for feature branches isn't recommended.

[Hunt, Lance]

Sorry for jumping in mid-stream on this topic, but I'm very interested in this discussion because my teams are increasingly finding the need for something equivalent to feature branches and have thus far enjoyed success with named branches as a solution.

I'm not sure I understand the reason for avoiding feature branches or the concern for "polluting other developers' default branch".   It seems to me that branching and merging are the core functions of a good (D)VCS.   Also, the cost of having multiple branches is relatively cheap due to how most modern (D)VCS store changes as diffs & changesets rather than full copies of entire files.

I would agree that feature branches might be problematic for frequently abandoned spike-branches and pure experimental changes, but for true feature-branches which will typically eventually be merged together with the mainline I don't see any problem.   There is very little difference between a named branch and an unnamed series of changesets created by out-of-sync peers working in the same codebase and ultimately merged prior to a push.  In fact, if those changesets didn't have a named branch associated then they would just be yet another branch/merge bubble that nobody would really take notice of.   Even then, you can close the branch if it still feels dirty after the merge to tidy things up a tad bit more.

Now if your problem is back with the experimental or discontinued branches that don't merge into any mainline or other history then arguably you probably should have used a separate repo for those changes.   That can even be rectified at the last minute (prior to push) by either abandoning your local repo and re-cloning, or by stripping your experimental changesets.

I'm still relatively new to Mercurial and DVCS, so am I missing some glaring problem with named branches?

Is the argument really that you should be forking rather than branching to solve this problem?

Thank you,

--Lance




*****Attention*****
This electronic transmission may contain confidential, sensitive, proprietary and/or privileged information belonging to the sender. This information, including any attached files, is intended only for the persons or entities to which it is addressed. Authorized recipients of this information are prohibited from disclosing the information to any unauthorized party and are required to properly dispose of the information upon fulfillment of its need/use, unless otherwise required by law. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by any person or entity other than the intended recipient is prohibited. If you have received this electronic transmission in error, please notify the sender and properly dispose of the information immediately.


-----Original Message-----
From: Peter Bourgon [mailto:mercurial.peter at bourgon.org]
Sent: Tuesday, July 05, 2011 1:23 PM
To: mercurial
Subject: Using named branches (`hg branch`) for feature branches isn't recommended.

> using named branches (`hg branch`) for feature branches isn't recommended.

I hashed this out on IRC a week or two ago. As far as I'm aware, there
is no alternative to named branches for feature branches which provide
all of the following characteristics:

  1. Allow feature branches to be cleanly made from the default branch.
  2. Allow developers to push their feature branches to a central
repo, without polluting other developers' default branch. (ie. "hg
pull ; hg update default" should never put feature-branch code in your
working directory.)
  3. No push -f required.

As far as I'm aware: Anonymous branches violate #3. Bookmark-based
solutions violate #2. I got a variety of suggestions which revolved
around the concept of doing primary development work from non-default
branches, which is not my team's workflow and violates #1.

Is there actually an alternative? If not, I have to admit that it's
rather frustrating to hear this line repeated by Hg devs.

Cheers,
Peter.