Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
Le 02/09/2013 18:36, Stephan Beal a écrit : Hi, all, i'm looking to prioritize some work on libfossil and i got the idea to try to find out which commands people use most often, and use that to help me prioritize. Hi! My main fossil usage is to sync my projects between two computers by the means of a third one, which is my home server. I use fossil too to update my Weblog. Therefore I think it is not a surprise that I use a lot of 1. ci (of course) 2. status 3. extra 4. push/pull/up (I dislike the autosync feature, because I prefer do things step by step and only push my changes (many atomic commits) to the server when it is ready...) 5. add/mv (I remove only a little file, compared to the ones I add or rename) In fact, I use a lot of status and extra automatically as I'm using liquidprompt (https://github.com/nojhan/liquidprompt) for which I've added fossil support. Good afternoon, -- Étienne Deparis http://etienne.depar.is/ twitter: @milouse ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 3:12 PM, Étienne Deparis etie...@depar.is wrote: In fact, I use a lot of status and extra automatically as I'm using liquidprompt (https://github.com/nojhan/**liquidprompthttps://github.com/nojhan/liquidprompt) for which I've added fossil support. Thanks for that tip - i'm trying it out now. A bit slow on my netbook, but usable. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On 9/2/2013 9:36 AM, Stephan Beal wrote: i'm looking to prioritize some work on libfossil and i got the idea to try to find out which commands people use most often, and use that to help me prioritize. I wonder how hard it would be for fossil to (optionally) keep the statistics you are interested in? Add a table keyed by fossil command, and simply count invocations of each command. The table could be global (wherever global settings are actually stored), per-repository, or per-checkout. In all three cases, fossil already has db connections to the right places, so the overhead should be relatively low. A new fossil test-command-stats command could then sort and dump the table. So... which fossil CLI commands do you use most often, NOT counting the following (which are more or less required for any real work): Aside from the obvious mandatory commands, I do use merge and extras. I (almost) never use close, and I rarely use stash. While I use the timeline a lot, I (almost) never do so from the CLI interface. Perhaps I'm unusual, but I do use branches even on private projects, where I want the benefit of a playground but need to be able to park that train of thought for a while and go back to whatever the core reason for the tool was. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 +1 626 351 1590 FAX ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 9:08 PM, Ross Berteig r...@cheshireeng.com wrote: I wonder how hard it would be for fossil to (optionally) keep the statistics you are interested in? That's an interesting question. Keeping them locally would be very little work, actually. Add a table keyed by fossil command, and simply count invocations of each command. The table could be global (wherever global settings are actually stored), per-repository, or per-checkout. Per repo is not easy because a rebuild removes any non-core tables and it wouldn't be worth the trouble to make all this stuff syncable. Adding a table to the checkout (which will be lost on a close) will be easy to do. That's a very good idea. Added to my list. Thanks! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 12:36 PM, Sergei Gavrikov
sergei.gavri...@gmail.comwrote:
history | gawk \
'{if($2==f||$2==fossil)s[$3]++}END{for(i in s)print s[i],i}'|sort -Vr
Nice use of awk! That one is going in my notes. -V doesn't work on the sort
available for me but -nr works nice. I keep most of my command line history
in an sqlite3 db. Unfortunately only unique commands are stored but the
stats from that are sort of interesting:
hs % | gawk '{if($1==f||$1==fossil||$1==fsl)s[$2]++}END{for(i in
s)print s[i],i}' | sort -nr
788 ci
200 add
125 commit
119 set
114 merge
98 rm
98 diff
91 help
91 co
83 repo
67 open
58 clone
51 user
46 update
46 sync
37 extras
35 branch
32 mv
30 gdiff
29 revert
26 tag
21 timeline
20 status
19 ui
19 info
14 remote-url
13 leaves
11 stash
11 checkout
10 settings
10 ls
10 finfo
8 new
8 bisect
7 rebuild
7 pull
6 ticket
6 serve
6 init
5 setting
4 up
4 test-move-repository
4 server
4 json
4 getrepo
4 createrepo
4 cat
4 all
3 history
3 annotate
2 wiki
2 version
2 unset
2 undo
2 test-canonical-name
2 shash
2 sett
2 reset
2 repol
2 log
2 changes
1 vlist
1 update;make
1 trunk
1 tkdiff
1 timeoline
1 time
1 testconfig
1 tech
1 submit
1 sqlite3
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RFC: new feature: CLI command stats collection
Hi, all, per Ross' suggestion in the top 5 commands thread, we now have a new feature: http://fossil-scm.org/index.html/timeline?r=usage-command (note that it's in a branch) Before trunking this, i'm looking for guinea pigs (ah, beta testers) to try it out, make suggestions, and potentially suggest a better name for the command. Usage is trivial: stephan@tiny:~/cvs/fossil/fossil/src$ f usage SQLITE_ERROR: no such table: cmd_usage (An sqlite error message is normal the first time this is run for a given checkout!) No command usage history has been collected for this checkout. ... stephan@tiny:~/cvs/fossil/fossil/src$ f usage CLI command usage history for this checkout: Count Command 3 usage 2 status 1 commit stephan@tiny:~/cvs/fossil/fossil/src$ f help usage Usage: f usage [-clear|-c] Reports or clears information from the local checkout's cmd_usage table (if any). The cmd_usage table is updated each time a fossil CLI command succeeds (returns). The db has (name TEXT, mtime FLOAT (Julian Day)) fields for collecting statistics about usage. This information is stored in the local checkout db and is not synchronized. stephan@tiny:~/cvs/fossil/fossil/src$ f usage -c Usage history cleared. stephan@tiny:~/cvs/fossil/fossil/src$ f usage CLI command usage history for this checkout: Count Command 1 usage :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 9:32 PM, Matt Welland estifo...@gmail.com wrote: All assuming of course that fossil won't be upset by extraneous stuff in the global_config table. AFAIK we have no mechanisms in place for managing the contents of that db. Hmm... off topic but interesting, apparently I have 177 checkouts of various repos. Undoubtedly most are defunct pointers. Is there an official way to clean up that table? You can just delete your ~/.fossil file and it will be created as needed. i've never poked around in there, but a quick glance suggests... sqlite3 ~/.fossil select count(name) from global_config where name like 'ckout:%'; 177 echo delete from global_config where name like 'ckout:%' | sqlite3 ~/.fossil (or equivalent) should do the trick. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 12:19 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Sep 3, 2013 at 9:08 PM, Ross Berteig r...@cheshireeng.com wrote: I wonder how hard it would be for fossil to (optionally) keep the statistics you are interested in? That's an interesting question. Keeping them locally would be very little work, actually. Add a table keyed by fossil command, and simply count invocations of each command. The table could be global (wherever global settings are actually stored), per-repository, or per-checkout. Per repo is not easy because a rebuild removes any non-core tables and it wouldn't be worth the trouble to make all this stuff syncable. Adding a table to the checkout (which will be lost on a close) will be easy to do. Why not (optionally) store them in ~/.fossil? Just create appropriate keys such as stats: concatenated with the command and then increment the value: name value - 'stats:ci' 11 'stats:extras'5 'stats:rm'2 All assuming of course that fossil won't be upset by extraneous stuff in the global_config table. Hmm... off topic but interesting, apparently I have 177 checkouts of various repos. Undoubtedly most are defunct pointers. Is there an official way to clean up that table? sqlite3 ~/.fossil select count(name) from global_config where name like 'ckout:%'; 177 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
On Tue, Sep 3, 2013 at 9:19 PM, Stephan Beal sgb...@googlemail.com wrote: That's a very good idea. Added to my list. Thanks! This isn't checked in yet, but a prototype is in place which automatically updates the stats only for CLI mode and only if the command succeeds (i.e. if it does not fatally exit, as most errors do). stephan@tiny:~/cvs/fossil/libfossil$ f usage SQLITE_ERROR: no such table: cmd_usage No command usage history has been collected for this checkout. stephan@tiny:~/cvs/fossil/libfossil$ f usage Count Command 1 usage ... stephan@tiny:~/cvs/fossil/libfossil$ f usage Count Command 2 status 2 usage 1 ls -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] survey: your top 5 most-used fossil CLI commands?
It seems for me it's good to know and the less-used commands :-)
Yesterday I checked my list as
% history | gawk \
'{if($2==f||$2==fossil)s[$3]++}END{for(i in s)print s[i],i}'|sort -Vr
Sergei
On Tue, 3 Sep 2013, Stephan Beal wrote:
On Tue, Sep 3, 2013 at 9:08 PM, Ross Berteig r...@cheshireeng.com wrote:
I wonder how hard it would be for fossil to (optionally) keep the
statistics you are interested in?
That's an interesting question. Keeping them locally would be very little
work,
actually.
Add a table keyed by fossil command, and simply count invocations of
each command. The table could be global (wherever global settings
are actually stored), per-repository, or per-checkout.
Per repo is not easy because a rebuild removes any non-core tables and it
wouldn't be worth the trouble to make all this stuff syncable. Adding a table
to
the checkout (which will be lost on a close) will be easy to do.
That's a very good idea. Added to my list. Thanks!
--
- stephan beal
http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RFC: new feature: CLI command stats collection
On 9/3/2013 1:07 PM, Stephan Beal wrote: per Ross' suggestion in the top 5 commands thread, we now have a new feature: Cool. Is that a record for shortest time from suggestion to release of a new feature? I came back from lunch to find a discussion of its implementation waiting for me Before trunking this, i'm looking for guinea pigs (ah, beta testers) to try it out, make suggestions, and potentially suggest a better name for the command. Sounds like I'd better update my local copy right after a meeting I'm late for I'll do that and abuse it for a while. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RFC: new feature: CLI command stats collection
On Tue, Sep 3, 2013 at 11:02 PM, Ross Berteig r...@cheshireeng.com wrote: On 9/3/2013 1:07 PM, Stephan Beal wrote: per Ross' suggestion in the top 5 commands thread, we now have a new feature: Cool. Is that a record for shortest time from suggestion to release of a new feature? i don't think so. i i think maybe the recent PGP Signed timeline bits (which i subsequently threw out) got done faster. And i'm certain i've seen other devs do similar things in the past. You just happened to suggest something that was easy to do and was helpful to me :). May you continue to have such luck in your feature ideas. I came back from lunch to find a discussion of its implementation waiting for me It was easy to implement. The whole diff is: http://fossil-scm.org/index.html/vdiff?from=fa0df0c77e670109to=e11bec70efae36e9sbs=1 Sounds like I'd better update my local copy right after a meeting I'm late for I'll do that and abuse it for a while. :) There's no rush. We're about to (this week?) do the 1.27 release and i probably won't trunk this until after that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] RFC: new feature: CLI command stats collection
Ok, since my meeting got pushed I decided to get the new usage command
in my local copy to abuse it for a while. I did
C:... fossil update tip
which (probably by blind luck) picked up the latest change [e11bec] to
the update-command branch. I then had to remember whether I last built
with MingW via CMD.EXE, via MSys bash, or from VS2010. I opened a VS2010
command prompt in my workspace, then did
C:... cd win; nmake /f Makefile.msc
which churned as usual, then turned up an error in the SQLite amalgamation:
..\src\sqlite3.c(108355) : error C2275: 'tRowcnt' : illegal use of this type as
an expression
..\src\sqlite3.c(8274) : see declaration of 'tRowcnt'
..\src\sqlite3.c(108355) : error C2146: syntax error : missing ';' before
identifier 'iLower'
..\src\sqlite3.c(108355) : error C2065: 'iLower' : undeclared identifier
..\src\sqlite3.c(108356) : error C2275: 'tRowcnt' : illegal use of this type as
an expression
..\src\sqlite3.c(8274) : see declaration of 'tRowcnt'
..\src\sqlite3.c(108356) : error C2146: syntax error : missing ';' before
identifier 'iUpper'
That isn't my elephant at the moment, but surely someone wants to know.
The build instructions for Windows might have suffered from a touch of
bitrot as well... and in any case I always want JSON enabled and I want
a working build sooner than it will take to figure out why SQLite and
VS2010 are having a tiff. So I turned to MinGW32.
C:... make -f win\Makefile.mingw
mkdir -p wbld
gcc -o wbld/translate src/translate.c
wbld/translate src/add.c wbld/add_.c
'wbld' is not recognized as an internal or external command,
operable program or batch file.
make: *** [wbld/add_.c] Error 1
Oops, clearly the MinGW makefile is assuming bash or a similar shell is
the command processor. So after one more fossil clean --force, we try
bash under MSys...
$ make -f win/Makefile.mingw
$ ./fossil help --all
has the new usage, but no json. Oh yes, I forgot about
configuration. So once more, fossil clean --force, with the intent to do
./configure make:
$ fossil clean --force
$ ./configure
problem with ZLib
which leads to a long garden path of build pain and annoyance starting
with building zlib itself, then the realization that it next wants
OpenSSL, and that I really don't want to go down this path. While it
would probably be a good idea to make ./configure better handle bash
running from the MSys environment, that also isn't my elephant for
today. So, back to the pre-configured Makefile.mingw, and the
recollection that it supported a conditional for enabling JSON:
$ fossil clean --force
$ make -f win/Makefile.mingw FOSSIL_ENABLE_JSON=1
$ ./fossil version
This is fossil version 1.26 [e11bec70ef] 2013-09-03 20:15:25 UTC
$ ./fossil help --all
3-way-mergeclose import redo tarball
addco info remote-url ticket
addremove commit init rename timeline
allconfiguration json revert ui
annotate dbstat leaves rm undo
artifact deconstructls scrub unset
bisect delete md5sum search update
branch descendantsmerge server usage
catdiff mv settings user
cgiexport newsha1sumversion
changesextras open sqlite3whatis
checkout finfo pull stash wiki
ci gdiff push status winsrv
clean help rebuildsync zip
clone http reconstructtag
$
$ fossil usage
CLI command usage history for this checkout:
Count Command
2 status
2 usage
1 clean
1 update
So far, so good, aside from the rocky garden path to remembering how I
usually build it here. I'll make this my usual fossil.exe and use it for
a while.
On 9/3/2013 2:26 PM, Stephan Beal wrote:
i don't think so. i i think maybe the recent PGP Signed timeline bits
(which i subsequently threw out) got done faster. And i'm certain i've
seen other devs do similar things in the past. You just happened to
suggest something that was easy to do and was helpful to me :). May you
continue to have such luck in your feature ideas.
I've certainly seen problems handled and fixes pushed to trunk in
remarkably short times. A whole new command, though...
There's no rush. We're about to (this week?) do the 1.27 release and i
probably won't trunk this until after that.
In your shoes I'd be torn between having the stats available from as
broad a user base as possible, and not pushing a brand new possibly
unstable feature into the wild in a rush. Its your call, obviously, but
I suspect I'd lean towards
