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