What is a branch?

Adrian Buehlmann adrian at cadifra.com
Sat Feb 9 04:33:53 CST 2008


On 09.02.2008 02:34, Stuart W. Marks wrote:
>> BTW on the Branch wiki page, I didn't write that a clone is a branch. 
> 
> Yes, I understand that. I was referring to other writings. For example, 
> on the QuickStart page
> 
> http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart
> 
> The "Branching and merging" example has the following line:
> 
>     $ hg clone project project-work    # create a new branch
> 
> This is clearly using the "clone is a branch" definition.

I agree that a repo clone is not a branch (looking at the state of the repo
clone directly after having cloned it). I may take a stab at tweaking QuickStart
after I hit the send button...

A clone is a potential branch. If you just clone and repeatedly pull to update
the "clone", it can remain a clone (a copy) for ever. Or a replica. Or should we
say a "repository clone" in that case?

A "repository clone" might not be the same as a repository that once was cloned
from another repo in the past. As such, the "cloned" repository looses its
status as a true clone as soon as you commit two *different* changesets to each
of them.

Maybe we should expand on that on the Clone page in addition.

>> The branching on the cloned repo does not happen until you *commit* 
>> two differing changesets in both clones. So, effectively, there is no 
>> difference to the single repo case. Semantically, that branching 
>> already happened on the commit of C2 in R2. Not just when you pull it 
>> into R1.
> 
> This differs yet again from the "clone is a branch" definition. I hadn't 
> heard "branch" used in this sense before,

I am just trying to be precise here. BTW, I generally don't think that
simplifications are helpful.

I agree that a clone is not a branch. But we just shouldn't goo too far with
that observation.

> but I see what you're driving
> at. This is sort of a latent branch, in that you can't necessarily see 
> it until changes are propagated.

The term "latent branch" is quite nice. That's a damn prominent reason for using
a DVCS (=Distributed Version Control System) in the first place.

>> The history graph is in fact a "distributed history graph". So the 
>> branch exists earlier. Per your terminology, the branch would not 
>> exist until I pull it into a  combining repo. So I'm not sure if your 
>> approach really does help to reduce any (supposed) confusion.
> 
> Sure, since you and I are using different definitions of "branch" it's 
> understandable that we'd say they are created at different times.

I'm not sure I really have a crisp definition of the term "branch" myself. I'm
more used to think in Mercurial command sequences currently.

I propose to cover multiple usages of the term "branch" on the Branch page. I
feel a style used like on Wikipedia -- which exactly does that -- isn't too bad.

> But I do think there is real confusion out there arising from ambiguity 
> around the word "branch". The recent thread "mercurial tip not visible" 
> is rife with this ambiguity.

I'm pondering whether the term "tip" itself is a source of confusion of its own.
I will have a look at the "Tip" wiki page....

> Well, maybe I'll just edit some of the wiki pages and see if people like 
> what I come up with.

Feel free to do so. I don't claim any ownership. Discussing is helpful, as you
already noted. Maybe we can adopt a discussion page pattern like the one
explicitly supported in the 1.6 release of MoinMoin (the wiki software
http://moinmo.in/, see also http://www.selenic.com/mercurial/bts/issue917),
which is:

The discussion page for page "Foo" is at the subpage "Foo/Discussion".

BTW, I've installed MoinMoin 1.6.0 on our local internal FreeBSD server. It
works quite nicely. Ahh, I see, there's already a 1.6.1 release :-)....


More information about the Mercurial mailing list