On Sun, 13 Jan 2013 12:58:10 +0100, Stephan Beal <sgb...@googlemail.com>
wrote:
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff
<veedeeh...@googlemail.com>wrote:
it's banal: the `-n' flag does not at all specify the _number_ of
timeline
entries to show (which one would expect!) but rather (probably) the
total
number of lines
Ah, right - i had forgotten about that (the JSON timeline is the one i
implemented and it uses -n as the _entry_ count).
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='ci';
4890
I believe that is the correct one for number of file checkins (identical
to the above `wc' output and there was no new file checkin since you
tried,
I believe).
My gut feeling is that that is the correct (or more correct) value, but
before changing that i need to verify with DRH that that's okay because
he
(i think) added the commit count in the /stat page and i'd need to change
that one as well (or maybe just change its label).
(note that i skipped over (e.type='g'))
?? which is what if a humble user may ask...??
LOL! i skipped them because i could not remember what they are :/. i see
now, via name.c, that they are "tag change" events.
ah! bug report: `fossil help timeline' does not say anything about
existence of a `g' type (and further?) types, although it accepts the flag
(and reports 287
entries in the present example).
so what would be nice to have the separate checkin types reported
separatly
(and mabye, though redundant also cumulatively (i.e. the 8802 in this
example). and, as I said, a way to enforce "show whole timeline" would
be
nice. maybe one could use `fossil timeline -n 0' for that???
The -n 0 flag change appears (to me) to be more difficult than it sounds
well, I'm not a CS guy: I would catch the `0' immediately after parsing
input and replace it by {some_rediculously_huge_number} just as if I had
entered the huge number in the first place. this would work for the rest
of the lifetime of the universe, probably.
because that value is part of the calculation for ancestor depth, and
therefore has side effects on the algorithm other than simply the output
length. It appears that when two branches merge, printing "n" revisions
becomes philosophically problematic because one needs to know which
ancestor to crawl back in order to satisfy "n". i'm quite certain i
didn't
think about that problem at all in the JSON-based timeline command :/.
i'll get the wiki/ticket counts added to the "info" page, but want to get
an OK from DRH before i change the commit count calculation (though my
of course.
analysis confers with yours - that the current count is not quite correct
or is "correct for some other definition of 'commit'").
which then would seemingly not be in accord with what a user is wanting to
know (namely the number of corresponding timeline entries, right?
many thanks for addressing this issue,
j.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
