Hiho,
On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
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 1|grep
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
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff
veedeeh...@googlemail.comwrote:
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
On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal sgb...@googlemail.comwrote:
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
analysis confers with yours - that the current count is not quite correct
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.comwrote:
In this case this basic information would always be simply there.
otherwise time required for generating this information obviously
See attached (if the list doesn't remove it), ignoring the question of
which commit count is correct for the moment.
I would exclude the headline (Repository Statistics:) from column width
computation (so reducing the white space amount between keys and values).
otherwise I like this
On Sun, 13 Jan, Stephan Beal wrote:
See attached (if the list doesn't remove it), ignoring the question of
which commit count is correct for the moment.
I'd lose the Repository Statistics: headline as well because it is
just a repetition of the command issued. A timeline command e.g. does
not
another minor thing: to decide whether to count the revisions starting
from 0 (offset relative to initial checkin) or from 1.
j.
On Sun, 13 Jan 2013 14:58:09 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Sun, Jan 13, 2013 at 2:41 PM, Stephan Beal sgb...@googlemail.com
wrote:
On Sun, Jan 13, 2013 at 3:13 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
I would exclude the headline (Repository Statistics:) from column width
computation (so reducing the white space amount between keys and values).
i didn't use that column for width determination - i used hard tabs
looks good
On Sun, 13 Jan 2013 15:42:22 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Sun, Jan 13, 2013 at 3:13 PM, j. v. d. hoff
veedeeh...@googlemail.comwrote:
I would exclude the headline (Repository Statistics:) from column width
computation (so reducing the white space amount
On Sun, 13 Jan, j. v. d. hoff wrote:
(Incidentally I did already put that one into the new wiki page
http://www.fossil-scm.org/fossil/wiki?name=Wish+List today)
While I agree with some points on the wish list, I strongly object to
the first one. If the user insist with force to commit
On Sun, 13 Jan 2013 18:48:30 +0100, Stefan Bellon sbel...@sbellon.de
wrote:
On Sun, 13 Jan, j. v. d. hoff wrote:
(Incidentally I did already put that one into the new wiki page
http://www.fossil-scm.org/fossil/wiki?name=Wish+List today)
While I agree with some points on the wish list, I
On Sun, Jan 13, 2013 at 3:52 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
looks good
The word came down from DRH that this is the correct SQL to use for
counting commits:
SELECT COUNT(*) from event where where type='ci';
and Richard cannot off-hand explain the 40-some-odd difference
On Sun, 13 Jan 2013 13:17:46 +0100, j. v. d. hoff veedeeh...@googlemail.com
wrote:
snip
yes, fossil naming scheme is somewhat ideosyncratic `st' should be the
canonical name for `timeline; anyway in order not to put off svn and hg
users ;-)
Idiosyncratic? I think it is beautifully
On Sun, 13 Jan 2013 18:48:30 +0100,
Stefan Bellon sbel...@sbellon.de wrote:
snip
Just for example: In my case, fossil is used in an automated environment
to store certain states of files. This is completely automated.
Then you are using fossil for a purpose for which it was not designed.
Lots
On Sun, 13 Jan 2013 20:12:09 +0100, Eric e...@deptj.eu wrote:
On Sun, 13 Jan 2013 13:17:46 +0100, j. v. d. hoff
veedeeh...@googlemail.com wrote:
snip
yes, fossil naming scheme is somewhat ideosyncratic `st' should be the
canonical name for `timeline; anyway in order not to put off svn and
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com
wrote:
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in
On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
checkin-count: 4845
however, I do see a total (files+wiki+ticket) of 8799 checkins and
fossil time -t ci -n 1|grep ^[0-9]|wc -l
yields 4009.
so what is `checkin-count' actually reporting??
Whatever is
hi,
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the total number of
revisions (by default or optional), more precisely, the number of file
commits (as it is called in `fossil help timeline) in the repo. the
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff veedeeh...@googlemail.com
wrote:
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the total number of revisions
(by default or optional), more precisely, the number of file
On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com wrote:
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in the /stat
page already (and in fossil json stat -full).
Don't tell my boss this,
On Thu, 10 Jan 2013 13:35:06 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 12:56 PM, j. van den hoff
veedeeh...@googlemail.com
wrote:
I would find it useful if `fossil info' (or `stat', `timeline', or a new
command) would provide a means/option to show the
On Thu, Jan 10, 2013 at 1:57 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
...works like a charm and saves lots of typing (locally chronological rev.
nums are much easier to memorize (and to type...) than sha1 hashes).
so I still think this would be useful.
Explained that way it does
On Thu, 10 Jan 2013 14:12:18 +0100
Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jan 10, 2013 at 1:57 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
...works like a charm and saves lots of typing (locally chronological rev.
nums are much easier to memorize (and to type...) than
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com
wrote:
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in
On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal sgb...@googlemail.com
wrote:
i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the status command because we have that info in
This number is the same one reported from the /stat page for number of
commits. i am not sure off-hand whether wiki edits and whatnot are
included.
(sent from phone from dentist office...)
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Jan 10, 2013 5:24 PM,
27 matches
Mail list logo
