Using branches

[Dustin Sallings]

On Jul 13, 2007, at 6:38 , Charles Pope wrote:

> Thank you Dustin. So your preference would be to keep multiple  
> copies, each
> effectively representing a different branch and then merge changes  
> across,
> as appropriate?

	Yes.  That's also pretty much what you do in centralized revision  
control systems commonly.  One tree per train of thought.

	Distributed systems make branching like this incredibly cheap,  
therefore you're more likely to do it more often.

> How does it typically work, when a number of people are sharing the  
> same set
> of branches? i.e. so all users are clear where to push changes to.

	This kind of feels more hypothetical.  I wouldn't think a *typical*  
branch would be shared among several developers but perhaps someone  
would want to share some of the work they're doing with someone else  
and can ``hg serve'' it or something.  This is the model that would  
be really useful for me at work.  There have been several times I've  
collaborated with one other person in my group in such a way that  
it'd be harmful for the whole group to see the unfinished work.

	If it's a branch that is common for a lot of developers, you can put  
it up as a different tree.  That's essentially what you do in, for  
example, subversion or perforce.  You get a particular path if you  
want the main branch, and a different path if you want a different  
path.  You can push to one or the other, and merge between them.

	Note that in both of these cases, it's pretty clear:  Push changes  
back whence the tree came.  If you're doing a micro branch, you're  
branching off of a local tree, and you push back into your local tree  
and then push that tree back upstream.  If you're doing a big branch,  
you clone it from an agreed-upon central place, and you push changes  
back there.

-- 
Dustin Sallings