Improvements for named branches - another Use Case

Declan McGrath declan at frogface.org
Sat Mar 29 16:28:23 CDT 2008


Hi folks,

New to this list and pretty new to mercurial and was just tracking the 
conversation on named branches as best I can. I've been using named branches 
to collaborate in a team of a few people where basically 
  - each dev has their own (long lived) named branch
  - each dev merges in their changes to default once they have been reviewed 
for acceptance into default

I'd like to raise this as some people have been asking why anyone bothers with 
named branches. Well, here's my two cents
a.) It means you can have one central propository which everyone pulls/pushes 
through for co-ordinatation and is the "real" repository for the team. I 
guess this is a bit like the CVS centralised model.
b.) One push or pull from the developer sync's everything. His own named 
branch and everyone elses.
c.) It's nice and quick to switch between branches. No cd'ing here or cloning 
there just quick switching. This is good for productivity and, if you (long 
term) plan to have a handful of long-lived named branches, it gives a nice 
context for the whole project. eg, do a 'hg branches' and you can see Pete's 
branch is in there, and maybe a special Testing branch is also in there and a 
Reviewed branch. It's like having a table of contents in a book, whereas 
cd'ing in and out of cloned repo's is like switching between books.
d.) The current gotcha is that you can't close/delete/whatever a branch. So it 
would be nice if I could have a pete_yaml_editor branch spawned off Pete's 
own branch as a short-lived one which could just closed when the feature is 
done.

Just to labour point (c) a bit, let's say we have 5 people in the world 
regularly working on a solution to the named branches problem we are 
discussing so much. Well, if the all worked on named branches in a single 
repo it's easy for a newcomer to 'discover' the branches of people working on 
it

default                        6210:3e6c59ad95db
pete_edge	                  6200:3a6c53ad95db
louis_edge	                  6200:3a2c53ad95dc
stewie_edge	          6200:3a6c53ad36da
homer_edge	          6200:3a6c53ad97db

This maybe goes a little against distributed source control but it's nice in a 
situation, like in a small company, where you might have clearly defined 
lines of development and subsystems.

Dec




More information about the Mercurial mailing list