On 4/4/2016 11:33 AM, Ross Berteig wrote:
On 4/2/2016 3:40 AM, Svyatoslav Mishyn wrote:
But why that commit [b6b50b12] is marked
as *FORK* in timeline.rss;
and as *BRANCH* in `fossil timeline`;
while here https://www.fossil-scm.org/index.html/info/b6b50b1244796110
looks like usual commit..
Oooh, that's weird.....
Possibly not all that weird after all.
At a quick glance at the current batch, it looks like it is calling any
node a *FORK* if there is more than one descendent.
Bingo. The source code here:
https://www.fossil-scm.org/index.html/artifact/09319f9b1c1b31cf4c6340f6ce36c0ba0d1f8fb0?txt=1&ln=186-192
clearly shows that it calls anything with more than one parent a MERGE
and more than one child a FORK. It even has MERGE/FORK if both cases are
true. Going out on a limb here, this was by design. A refinement would
be to distinguish the case of a branch point from a fork, with the
additional complication of a node that might be both, or even both and a
merge point. (The same decision is made in the fossil rss command as well.)
So that raises the question of complexity versus clarity. From the
definitions published in the documentation here:
https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki
a branch point is a special case of a fork, even if it is strongly
intended to be the only kind of fork that normally occurs.
I wouldn't oppose a change to the RSS feed however, if there's an easy
way to do the right thing. I just don't have that fix at my fingertips.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
