On Sun, 13 Jan 2013 14:37:38 +0100, Stephan Beal <sgb...@googlemail.com>
wrote:
On Sun, Jan 13, 2013 at 2:16 PM, j. v. d. hoff
<veedeeh...@googlemail.com>wrote:
In this case this basic information would always be "simply there".
otherwise time required for generating this information obviously does
scale very badly for big projects. but maybe this is too naive?
That's the question - whether that's too naive or not. My gut feeling is
that the cache could easily get out of sync, but i could be quite wrong.
We
might also have problems with _other_ operations becoming arbitrarily
longer because of the addition of cache re-calculation.
I could even imagine
...numbers would become supported in relevant fossil commands such as
`diff', `merge', etc. this might of course be all nonsense and not in
accord with the actual design of fossil...
That's a topic i'm trying personally to stay away from because i think
it'd
be a messy divergence from fossil's world view. That doesn't in any way
don't really know about this "world view".
mean the idea is rejected, it just means i personally don't like it.
which is fine, of course. I've simply noted that in approx 5 years of `hg'
usage (which supports, both, hashes and rev. nums) I've never ever used
once the hash directly. rev. nums are so much easier to type and memorize.
if they don't come at some point in the future, it's OK (since not _that_
important), but in terms of ease of CLI use it is a disadvantage, I'd
maintain.
looks fine. cosmetic proposal: probably left-adjusted two column
(key/value) output would be easier to read (i.e. align everything in the
"value" column to match the space required by the longest key name
(Duration of Project in the above output, that is) and don't wrap long
lines.
The wrapping was either my console or gmail. i tried aligning but the
wide
variation in labels and values just looked funny to me. i'll try
not a big issue anyway.
diverging
from the /stat-derived labels and move to something more
machine-readable,
analog to how the "info" command works. i've also renamed it to dbstat,
per
your suggestion. On the dev list i've posted the question about which
query
is correct for the commit counts (and why), so hopefully we'll hear a
definitive answer from Richard on that.
Number Of Check-ins: 4890
Number Of Files: 749
I think the _total_ number of all checkins might also be helpful since
this would be the relevant number if chronological revision numbers
would
occur at some point in the future.
The output currently uses both calculations:
Number Of Check-ins: 4846
Number Of Files: 749 (4890 changes)
what I actually meant is "number of file changes plus number of wiki
changes + ...", i.e. the cumulative count of all date/time-tagged entries
in the full timeline output. if there is a nomenclature problem lurking
here, one might disambiguate via "tot. number of timeline entries" or
similar but that _should_ be synonymous to
number of checkins AFAICS. anything else would at least be rather
counter-intuitive in my view.
but i don't see how those line up, numerically speaking (more changes
than
checkins?). Richard will be able to explain to us those two different
values and what they _really_ mean. The first one uses the calculation
from
the /stat page and the second one uses a query against 'ci' events.
in my view, yes. or rather either use "commits" also for Wiki and Tickets
or use "changes" for `Files', too. I'd prefer "checkins" everywhere,
actually).
i'm currently using "changes" because i want to avoid any confusion with
any formal definition of commit/checkin.
Once the question regarding commit/checkin counting is clarified i'll get
this "change" "checked in."
--
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
