hgweb page with hg log -b <branchname>

Johan Samyn johan.samyn at gmail.com
Sat Jan 9 10:12:22 CST 2010


2010/1/9 Dan Villiom Podlaski Christiansen <danchr at gmail.com>:
> On 9 Jan 2010, at 10:28, Johan Samyn wrote:
>
>> 2010/1/9 Mads Kiilerich <mads at kiilerich.com>:
>>> FWIW I had DAG branches in mind, not named branches. That makes a
>>> difference, but they might have a lot in common anyway.
>>>
>> Mads, could you explain to me what you mean by the difference between
>> a named branch and a DAG branch ? For example (letters respresent
>> revision numbers obviously) :
>> A - B - C - D - F - G - K (default)
>>            \
>>             E - H - I - J (feature1)
>> To me a (named) branch is simply the group E-H-I-J (or even
>> A-B-C-D-F-G-K), which was given a name that is registered in each cset
>> along that line.
>
> A DAG branch consists of a changeset and all its ancestors. A named branch consists of all changesets whose metadata mark them as belonging to the given branch. In your example, there are two named branches — EHIJ & ABCDFGK — and two DAG branches — ABCDFGK & ABCEHIJ.
>
> An extended example:
>
>                                N (feature1)
>                               /
>                          L - M  (feature2)
>                         /
> A - B - C - D - F - G - K (default)
>          \
>           E - H - I - J (feature1)
Two remarks about the splitting/restarting of the feature1 branch :
*) Currently hgweb is not able to show the extra head(s) for a named
branch (tried that out on a little test repo).
*) Can you give me a real life example for wanting to do this ?

>
> The DAG branches, in this case, would be:
> * ABCDFGKLMN
> * ABCEHIJ

Shouldn't that be 'the dag branches for feature1, in this case ...' ?
Cause I'm not sure why you don't consider these ones as DAG branches too :
*) ABCDEFLM
*) ABCDFGK
Unless I'm still missing some point about what DAG branches really are ?

>
> The named branches would be:
>
> * ABCDFGK (default)
> * EHIJ, N (feature1)
> * LM (feature2)
>
> The ‘feature1’ branch has two DAG heads, which are also global repository heads. Adding a merge of M and K would cause the entire history of the repository to form a single DAG branch, and — assuming it was tagged as belonging to the ‘feature1’ branch — cause ‘feature1’ to only have one branch head.
Can you draw me what merging M and K would yield please ? Cause I
don't see how that merge could eliminate the second head on feature1
(unless you merge J with the result of the previous merge too).

>
> A DAG branch refers to a changeset and all its ancestors, possibly traversing merges, and can only have a single head. A named branch refers to all changesets with include the branch name in their metadata; it can have zero or more heads, with zero meaning that the branch doesn't exist in the repository. Additionally, named branches may be non-linear, and only contain parts of DAG branches. Given a changeset, it may belong to one or more DAG branches. In contrast, no changeset can be part of more than one named branch, and all changesets belong to one named branch.
>
> Personally, I'd prefer distinguishing the two kinds of branches by consistently restricting the word ‘branch’ to only refer to named branches.[1] Depending on the context, DAG ‘branches’ could be referred to as either heads, lines-of-development or ancestors. Using the same word for two fairly distinct concepts is likely to lead to confusion.[2]
>
> If you consider interoperability with the nomenclature of other version control systems, things are even more complicated. Historically, CVS and Subversion have no notion of an unnamed branch, so ‘branch’ must by necessity refer to a named branch. Git, on the other hand, has either little or no notion of a named branch[3] and so its users take the word ‘branch’ to refer to a DAG branch.
>
> [1] Needless to say, this restriction would apply to UI and documentation; freedom of speech endures!
> [2] Such as the one you (Johan) appear to suffer from ;)
> [3] Git repositories appear to use sliding tags; comparable to Mercurial bookmarks. I can't say whether Git has actual support for named branches, but if it does, it appears to see little use.
>
> --
> Dan Villiom Podlaski Christiansen
> danchr at gmail.com
>
>
Thanks for explaining Dan.
Given my remarks/questions above, I don't think I got it completely yet.
So I'm eager to read your reply, as this subject seems rather
important, and interesting.
Johan


More information about the Mercurial-devel mailing list