Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 ^[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 1|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). 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 info (or the /stat page) says: stephan@tiny:~/cvs/fossil/fossil$ f info ... checkin-count: 4846 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 sqlite select count(*) from blob b JOIN event e where b.rid=e.objid and e.type='w'; 282 and events: sqlite select count(*) from blob b JOIN event e where b.rid=e.objid and e.type='e'; 4 For a total number of repository events (not to be confused with Event entries) of: sqlite select count(*) from event; 8802 (note that i skipped over (e.type='g')) 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: , bug ci: ) 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 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. Thoughts? -- - 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] `fossil info' feature request (a.k.a. wish)
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.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 ^[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 1|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 `1' 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 100|grep ^[0-9]|wc -l' yields 4890 `fossil info' yields checkin-count: 4846 so there's still a discrepancy. `fossil time -n 100|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: , bug ci: ) 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 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. 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 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 analysis confers with yours - that the current count is not quite correct or is correct for some other definition of 'commit'). -- - 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] `fossil info' feature request (a.k.a. wish)
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 or is correct for some other definition of 'commit'). Eeek... adding them is simple but they pose another problem: the first run takes about 5 seconds for that query on my netbook. The second, once the OS has cached at the filesystem level, is much faster. Before i go murdering the performance of the info command it might make sense to add a CLI version of the stat page, with the caveat that that will upset users who currently enter stat as a shortcut for status (when stash was implemented it upset me because it broke me of my st==status habit ;). Let me think a bit about this, but i think moving this info into a 'stat' command is the right thing to do. -- - 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] `fossil info' feature request (a.k.a. wish)
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 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 column-adjusted output better than the irregular default. actually, I think several fossil commands (notably info and stat) could profit from the same beautification. :-? PS: i like the name stats better, but don't want to break anyone's stat==status habit :/. +1 (and `dbs' would be a nice acronym). -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 start with Checkout Timeline: either. And then I'd remove one hyphen from the wiki-page-count to wikipage-count because the other counts just have one hyphen as well. That makes it easier to parse for all counts - if one has to. Apart from that, fine with me. Greetings, Stefan -- Stefan Bellon ___ 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] `fossil info' feature request (a.k.a. wish)
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: I hope you can take that into consideration when implementing the final statistics command. Yes, of course :). i appreciate your feedback. See attached (if the list doesn't remove it), ignoring the question of which commit count is correct for the moment. :-? PS: i like the name stats better, but don't want to break anyone's stat==status habit :/. -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 and let the terminal figure it out (which means it will probably break on Windows ;). Using only 1 tab isn't cutting it, though, because server-id is too short. i'll remove that top line, though - Stefan's argument that it is redundant sounds good to me. @Stefan: the argument for wikipage instead of wiki-page - i'm not convinced that that would simplify anything, but this feature is for you guys, so i've changed that, too. ... i've re-done the spacing to use normal spaces instead of tabs, so it now looks like: stephan@tiny:~/cvs/fossil/fossil$ f dbstat repository-size:35969024 bytes (36.0MB) artifact-count: 19497 (stored as 5369 full text and 14128 delta blobs) artifact-sizes: 52103 bytes average, 4993770 bytes max, 1015763428 bytes (1.0GB) total compression-ratio: 28:1 checkin-count: 4846 file-count: 749 (4890 changes) wikipage-count: 23 (282 changes) ticket-count: 990 (3137 changes) project-age:2004 days or approximately 5.49 years. project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: c7d762ef2a202474a9d04a38050f1c789b2fc771 fossil-version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2) sqlite-version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16) database-stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8, delete mode (line-wrapping is the mail client) -- - 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] `fossil info' feature request (a.k.a. wish)
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 between keys and values). i didn't use that column for width determination - i used hard tabs and let the terminal figure it out (which means it will probably break on Windows ;). Using only 1 tab isn't cutting it, though, because server-id is too short. i'll remove that top line, though - Stefan's argument that it is redundant sounds good to me. @Stefan: the argument for wikipage instead of wiki-page - i'm not convinced that that would simplify anything, but this feature is for you guys, so i've changed that, too. ... i've re-done the spacing to use normal spaces instead of tabs, so it now looks like: stephan@tiny:~/cvs/fossil/fossil$ f dbstat repository-size:35969024 bytes (36.0MB) artifact-count: 19497 (stored as 5369 full text and 14128 delta blobs) artifact-sizes: 52103 bytes average, 4993770 bytes max, 1015763428 bytes (1.0GB) total compression-ratio: 28:1 checkin-count: 4846 file-count: 749 (4890 changes) wikipage-count: 23 (282 changes) ticket-count: 990 (3137 changes) project-age:2004 days or approximately 5.49 years. project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 server-id: c7d762ef2a202474a9d04a38050f1c789b2fc771 fossil-version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2) sqlite-version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16) database-stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8, delete mode (line-wrapping is the mail client) -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 without a commit message, then the tool should not try to be smart and prohibit the commit. As long as it will not cause operational problems for the tool itself, it is always wrong if the tool tries to be smarter than the user. Even more so if the user explicitly stated yes, I know, but that's what I want. Just for example: In my case, fossil is used in an automated environment to store certain states of files. This is completely automated. Those commits of course could get the date/timestamp as commit message, but that would be redundant, so why should a commit message be forced in such automated environments? It does not make sense. Do not assume your workflow or setup for everybody else. If the tool does not need the information, do not enforce its presence! Greetings, Stefan -- Stefan Bellon ___ 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] `fossil info' feature request (a.k.a. wish)
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 strongly object to the first one. If the user insist with force to commit without a commit message, then the tool should not try to be smart and prohibit the commit. As long as it will not cause operational problems for the tool itself, it is always wrong if the tool tries to be smarter than the user. Even more so if the user explicitly stated yes, I know, but that's what I want. Just for example: In my case, fossil is used in an automated environment to store certain states of files. This is completely automated. Those commits of course could get the date/timestamp as commit message, but that would be redundant, so why should a commit message be forced in such automated environments? It does not make sense. Do not assume your workflow or setup for everybody else. If the tool does not need the information, do not enforce its presence! I don't claim/believe that all points on the list will qualify for a majority vote. I've just collected them and put them there due to drh's suggestion (with some misgivings that it would cause partly too much noise afterwards on the list -- your mail explicitely _not_ rated as such, but let's see what else will come up...). regarding the issue at hand, from my perspective, in _interactive_ use I _never_ want an empty commit message (nor should anybody _want_ this, right?), so interpretation of leaving the commit-message-editor directly without any edits as aborted commit (notifying the user to that extent automatically) is very sensible (I like this behaviour, e.g. in `hg'). but I simply don't like to answer a (for me) redundant question, whether I really want to abort or not when I _do_ decide to abort the commit and, therefore, leave the editor immediately again. for your use case a new `-f(orce)' flag for `ci' to enforce commit without ci message would sure achieve what you (and maybe others) want (and that would be the machine typing too much, not me ;-)). making the behaviour user configurable (e.g. via `set') might be another idea. anyway, I _don't_ have too strong feelings about this point. j. Greetings, Stefan -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 between that and the mlink count approach (that used on /stat). This particular repo is (AFAIK) the only one in the world which has survived literally every bug fossil has ever had, and it's possible (but unconfirmed) that that discrepancy is due to an ancient bug which was fixed years ago. i'll be trying to figure that out in the coming days. What i'm about to check in looks a tiny bit different than earlier: stephan@tiny:~/cvs/fossil/fossil$ f dbstat ... checkin-count: 4890 file-count: 749 wikipage-count: 24 ticket-count: 990 ... i have left out the number of changes per type for the time being so that i can verify those/my approach for counting those (but that won't happen tonight). Okay, so here we go... http://www.fossil-scm.org/index.html/info/1dd493231a i'll look into the change-counts later on in the week. Happy Hacking! -- - 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] `fossil info' feature request (a.k.a. wish)
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 simple: When you write the entry C-function for a command, you put a comment line like ** COMMAND: cmdname Above it. You can put more than one to give the command multiple names. Then at build time the mkindex utility builds a constant table used to map command names into functions. When you type fossil xy, that table is searched for entries beginning with xy. If there is only one, it is run, if there is more than one fossil tells you what they are and quits. You are suggesting making a non-unique prefix run a totally different command. How much confusion is that going to cause? Actually you are suggesting changing fossil to make it more like some other program, and you know _my_ opinion of that. In any case, it doesn't work. There is no canonical. Unless one program is a clone of another there will not be a complete 1-1 mapping between commands, so you can't make all the commands have the same names. Eric -- ms fnd in a lbry ___ 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] `fossil info' feature request (a.k.a. wish)
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 of people use lots of VCS's for a similar purpose, for which (as far as I know) none of them were designed. Not going to try to change the universe here, but... Those commits of course could get the date/timestamp as commit message, but that would be redundant, so why should a commit message be forced in such automated environments? It does not make sense. Since it is automated, why not automate the same one or two word message for all the commits? I actually do that, in spite of what I said above, but I also have a directory with some bits of code in it which may one day be a program that _is_ designed for that :) Do not assume your workflow or setup for everybody else. But you can still say something if they are using a claw-hammer to undo a nut. Eric -- ms fnd in a lbry ___ 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] `fossil info' feature request (a.k.a. wish)
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 hg users ;-) Idiosyncratic? I think it is beautifully simple: When you write the entry C-function for a command, you put a comment line like ** COMMAND: cmdname Above it. You can put more than one to give the command multiple names. Then at build time the mkindex utility builds a constant table used to map command names into functions. When you type fossil xy, that table is searched for entries beginning with xy. If there is only one, it is run, if there is more than one fossil tells you what they are and quits. You are suggesting making a non-unique prefix run a totally different no I don't -- saw the smiley? command. How much confusion is that going to cause? Actually you are suggesting changing fossil to make it more like some other program, and you know _my_ opinion of that. In any case, it doesn't work. There is no canonical. Unless one program is a clone of another there will not be a complete 1-1 mapping between commands, so you can't make all the commands have the same names. Eric -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). I just tested it and I stumbled: the reported checkin count is _approximately_ (order of magnitude...) correct but does _not_ match the actual number of checkins (nor the number of file checkins only). 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 ^[0-9]|wc -l yields 4009. so what is `checkin-count' actually reporting?? 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: , bug ci: ) is also of interest. thanks j. ps: in the long run I would really like to have fossil report chronological local revision numbers in the timeline (cumulative across files, wiki, tickets) in addition to the hashes (plus abilitity to use themas alias in all commands currently requesting specification of hashes). that would be at least nice to have in order to facilitate interaction with fossil, notably when using commands like `diff', `cat', etc. [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 shown in the /stat page. i re-used the same query as that code uses, but i'm not familiar enough with the semantics of the mlink table to say with absolutely certainty what it's counting (it seems to me to be the number of normal (file-level) commits). 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: , bug ci: ) is also of interest. i'll add wiki/ticket commit/change counts to the todo list for Sunday. (i'm about to leave town until then.) ps: in the long run I would really like to have fossil report chronological local revision numbers in the timeline (cumulative across files, wiki, tickets) in addition to the hashes (plus abilitity to use themas alias in all commands currently requesting specification of hashes). that would be at least nice to have in order to facilitate interaction with fossil, notably when using commands like `diff', `cat', etc. @DRH: perhaps we could abuse the rid for this purpose? AFAIK those have never been published as stable/external numbers? They wouldn't be strictly sequential (there'd be gaps in, e.g., the list of commit numbers b/c the blob table holds all types of artifacts), but this sounds like it might not be all that invasive. -- - 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
[fossil-users] `fossil info' feature request (a.k.a. wish)
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 information should be there in the database (or could be added?) and an additional line of output in `fossil info' would then do the trick. (sure one could also write a script analyszing `fossil timeline -ci ...' output to derive this information but this is not desirable for large repos in my view.) I would appreciate consideration of this proposal. greetings, j. ps: while I'm at it: adding the relative revision numbers to the output of `fossil timeline -ci' _and_ making them acceptable as keys instead of the SHA1 hashes in the relevant commands (notably `diff') would be very nice, too, but probably require more substantial changes. -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 commits (as it is called in `fossil help timeline) in the repo. the information should be there in the database (or could be added?) and an additional line of output in `fossil info' would then do the trick. (sure one could also write a script analyszing `fossil timeline -ci ...' output to derive this information but this is not desirable for large repos in my view.) 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). ps: while I'm at it: adding the relative revision numbers to the output of `fossil timeline -ci' _and_ making them acceptable as keys instead of the SHA1 hashes in the relevant commands (notably `diff') would be very nice, too, but probably require more substantial changes. The DVCS model means that _relative_ (sequential) revision numbers are rendered absolutely meaningless because multiple users can work offline in parallel (and their system clocks might not be properly synced, breaking time-based ordering). The sequential numbering problem is, in effect, impossible to solve in a DVCS. -- - 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] `fossil info' feature request (a.k.a. wish)
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, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 -- - 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] `fossil info' feature request (a.k.a. wish)
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 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 information
should
be there in the database (or could be added?) and an additional line of
output in `fossil info' would then do the trick. (sure one could also
write
a script analyszing `fossil timeline -ci ...' output to derive this
information but this is not desirable for large repos in my view.)
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).
ps: while I'm at it: adding the relative revision numbers to the output
of
`fossil timeline -ci' _and_ making them acceptable as keys instead of
the
SHA1 hashes in the relevant commands (notably `diff') would be very
nice,
too, but probably require more substantial changes.
The DVCS model means that _relative_ (sequential) revision numbers are
rendered absolutely meaningless because multiple users can work offline
in
parallel (and their system clocks might not be properly synced, breaking
time-based ordering). The sequential numbering problem is, in effect,
impossible to solve in a DVCS.
I'm aware of this and that's why I wrote relative in the first place.
still, the numbers do make sense _locally_ as a very handy means of
denoting/selecting a revision. confusion _could_ arise if different people
talk about revision 11 without being aware that this is no good and they
need to use the sha1 hash (but practically, this should not be an issue).
by the way, the idea is not mine anyway but stolen from mercurial which
does just that, namely reporting the time line with identifiers formatted
as {rel_rev_number}:SHA1 and both (the rel. rev. and the hash) are
accepted in `diff' and friends.
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.
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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 sound useful but i would personally be very wary of using any numbering/IDs which aren't guaranteed to be stable between CLI invocations, since a pull/update could invalidate/change the meaning of the ordering. (But that's just a sign of my own pedanticness.) -- - 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] `fossil info' feature request (a.k.a. wish)
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 sha1 hashes). so I still think this would be useful. Explained that way it does sound useful but i would personally be very wary of using any numbering/IDs which aren't guaranteed to be stable between CLI invocations, since a pull/update could invalidate/change the meaning of the ordering. (But that's just a sign of my own pedanticness.) You always can commit to (in my case) stable branch with a tag, f.ex. fossil commit -m Release version 5.2 --branch stable --tag 5.2 Perhaps i'm using it the wrong way, don't know, -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- Eduardo Morras emorr...@yahoo.es ___ 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] `fossil info' feature request (a.k.a. wish)
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 the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 thank you! -- 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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 the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/fossil]$ f info project-name: Fossil ... checkin-count: 4840 did not yet recompile and test, therefore short question: this is the total number of checkins (including wiki edits etc)? contrary to my last mail this would be actually the relevant info needed for creating the rel. checkin numbers I was talking about. 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
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, j. van den hoff veedeeh...@googlemail.com wrote: 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 the /stat page already (and in fossil json stat -full). Don't tell my boss this, but... http://fossil-scm.org/index.**html/info/acea7010b8http://fossil-scm.org/index.html/info/acea7010b8 i added the output to info instead of status because that seemed to be the better place for it (status reports local change status). [stephan@host:~/cvs/fossil/**fossil]$ f info project-name: Fossil ... checkin-count: 4840 did not yet recompile and test, therefore short question: this is the total number of checkins (including wiki edits etc)? contrary to my last mail this would be actually the relevant info needed for creating the rel. checkin numbers I was talking about. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
