On Sun, 13 Jan 2013 11:38:17 +0100, Stephan Beal <sgb...@googlemail.com>
wrote:
Hiho,
hi,
the numbers I'm going to report refer to this night's `a0dd5' being at the
top (I presume that's the same state you are looking on?):
On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff
<veedeeh...@googlemail.com>wrote:
e.g. for the fossil repo itself (as of today at e4ca677a6c), `fossil
info'
reports
checkin-count: 4845
however, I do see a total (files+wiki+ticket) of 8799 checkins and
fossil time -t ci -n 11111|grep ^[0-9]|wc -l
yields 4009.
i just tried that grep and still get the same 4009, though there have
been
commits since then that time:
stephan@tiny:~/cvs/fossil/fossil$ f time -t ci
=== 2013-01-13 ===
02:01:18 [a0dd51e9af] *CURRENT* Allow the FOSSIL_USER environment
variable
to
be used as a fallback when creating a new repository. (user:
mistachkin tags: trunk)
...
stephan@tiny:~/cvs/fossil/fossil$ f time -t ci -n 11111|grep ^[0-9]|wc -l
4009
So apparently there's a flaw with that counting logic (but i don't see
what
it is off hand).
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
displayed. and `11111' simply was to small. so that number has to be
increased 10 or a 100 times to be on the safe side. (side note: there
_should_ be a flag/setting for timeline enforcing display of the complete
timeline I'd say...). so:
`fossil time -t ci -n 1111100|grep ^[0-9]|wc -l' yields
4890
`fossil info' yields checkin-count: 4846
so there's still a discrepancy.
`fossil time -n 1111100|grep ^[0-9]|wc -l' yields
8802.
so what is `checkin-count' actually reporting??
i tried a second query for this and get results comparable (but not
identical) to the /stat page:
stephan@tiny:~/cvs/fossil/fossil$ sqlite3 ../fossil.fsl
...
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).
"info" (or the /stat page) says:
stephan@tiny:~/cvs/fossil/fossil$ f info
...
checkin-count: 4846
yes, that's the same number I see.
version: This is fossil version 1.25 [0fb6c829f2] 2013-01-08 16:55:39 UTC
For ticket and wiki modifications i get these numbers:
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='t';
3137
corresponding `grep|wc' yields the same.
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='w';
282
corresponding `grep|wc' yields the same.
and events:
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='e';
4
not derivable from timeline output AFAICS.
For a total number of repository "events" (not to be confused with
"Event"
entries) of:
sqlite> select count(*) from event;
8802
which again is identical to what the respective `grep|wc' yields (see
above).
(note that i skipped over (e.type='g'))
?? which is what if a humble user may ask...??
what I currently would find most useful is to see the total number (8799
in the example), but maybe instead a more
detailed statistics (file ci: xxx; wiki ci: yyyy, bug ci: zzzz) is also
of
interest.
The wiki/ticket change counts seem to [me to] be quite unambiguous, but
i'm
still not sure which of these two queries is "more correct" for file
commits:
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='ci';
4890
this one.
or
sqlite> SELECT count(distinct mid) FROM mlink;
4846
While the former "seems" to me to be correct, the latter has been in use
since Ancient Times in the /stat page, so i suspect that it is the
correct
one.
no. the first one is correct according to timeline output.
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???
j.
Thoughts?
--
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
