Re: [fossil-users] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 6:58 PM, Richard Hipp wrote: > > On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote: > >> >> http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg >> >> >> I'll see what I can do about enhancing Fossil with an "approaching puma" >> warning (warnings that a fork has occurred) and a "shoot puma with sidearm" >> command (fossil merge with no argument). >> > > Latest Fossil on trunk contains two new features: > > (1) Typing just "fossil merge" without a version argument will attempt to > merge any forks that exist on the current trunk. No need to go looking up > the version number of the fork - Fossil will figure it out automatically. > > (2) After each commit in auto-sync mode, Fossil now does both a push and a > pull. (Formerly it only did the push.) The extra pull means that if a > fork occurred due to a race, it will be detected and a warning message will > be printed. Both new features seem to work well for me. Thanks! > -- > D. Richard Hipp > d...@sqlite.org > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://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
Re: [fossil-users] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote: > > http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg > > I'll see what I can do about enhancing Fossil with an "approaching puma" > warning (warnings that a fork has occurred) and a "shoot puma with sidearm" > command (fossil merge with no argument). Latest Fossil on trunk contains two new features: (1) Typing just "fossil merge" without a version argument will attempt to merge any forks that exist on the current trunk. No need to go looking up the version number of the fork - Fossil will figure it out automatically. (2) After each commit in auto-sync mode, Fossil now does both a push and a pull. (Formerly it only did the push.) The extra pull means that if a fork occurred due to a race, it will be detected and a warning message will be printed. -- D. Richard Hipp d...@sqlite.org ___ 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] Unintentional fork/race condition
On Sun, 13 Jan 2013 20:36:50 +0100, Ramon Ribó wrote: > >There is no rollback, an commit has been done. I >suppose you mean > >to reverse the commit > > I know it is not there. This is exactly the reason for me to write this > email. Sorry for being less than clear - I mean that a rollback is not possible, that is what the rest of my message was about. Your extra detail (not quoted) does not change this. 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 wrote: On Sun, 13 Jan 2013 13:17:46 +0100, "j. v. d. hoff" wrote: 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] Unintentional fork/race condition
>There is no rollback, an commit has been done. I >suppose you mean >to reverse the commit I know it is not there. This is exactly the reason for me to write this email. My proposal would of course require some kind of rollback or undo for the commit that would be automatically executed when detecting the possible fork and after having canceled the synchronization. If someone needs more details: - check that local repository would not fork - write somewhere the tip name - commit - sync with a precondition: if tip of the remote repository is not the same than tip of the local repository, abort synchronization. In this latter case, rollback or undo the commit RR El 13/01/2013 20:12, "Eric" va escriure: > On Sun, 13 Jan 2013 16:35:11 +0100, Ramon Ribó > wrote: > > In my opinion, the solution is more simple. Instead of: > > > > - sync > > - stop if would fork > > - commit > > - sync > > > > The procedure should be: > > > > - commit > > - sync > > - rollback if would fork > > There is no rollback, an commit has been done. I suppose you mean > to reverse the commit, but you can't do that. Apart from it being a > key part of fossil that everything is immutable, you still can't do > it. Which repository do you undo the commit in, the one synced to or > the one synced from? What happens to other repositories? What if someone > else does a commit based on the one you are reversing? The only way to > deal with those is to stop fossil being distributed! > > Anyway the issue is not that forks can happen (which is inevitable), > but that users should know they have happened and be able to deal > with them. > > 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 > > ___ 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] Unintentional fork/race condition
On Sun, 13 Jan 2013 07:48:59 +0200, John Found wrote: > On Sat, 12 Jan 2013 21:22:28 -0800 > "Michael L. Barrow" wrote: > > > > > Please stop trolling > > > > I am not trolling. I am prepared to believe you but I can see how tone and content might make people believe that. > It is "Reductio ad absurdum" that proves D. Richard Hipp is wrong in > his statement. It isn't, and it doesn't. Your extrapolation introduces factors which were not originally there. > Solving technical problems by high-handed methods is wrong by definition. It is not a technical problem. Fossil is a loosely-connected distributed system, and what happens with forks is a consequence of that. Any technical way of preventing them or dealing with them automatically will make fossil something other than what it was intended to be. The answer does lie in choosing appropriate working practices (workflow if you like), and if making those choices ends up looking "high-handed" then by all means suggest alternative working practices, and even changes to fossil to help with them, but not changes which contradict the basic principles of the software. 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 wrote: > 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] Unintentional fork/race condition
On Sun, 13 Jan 2013 16:35:11 +0100, Ramon Ribó wrote: > In my opinion, the solution is more simple. Instead of: > > - sync > - stop if would fork > - commit > - sync > > The procedure should be: > > - commit > - sync > - rollback if would fork There is no rollback, an commit has been done. I suppose you mean to reverse the commit, but you can't do that. Apart from it being a key part of fossil that everything is immutable, you still can't do it. Which repository do you undo the commit in, the one synced to or the one synced from? What happens to other repositories? What if someone else does a commit based on the one you are reversing? The only way to deal with those is to stop fossil being distributed! Anyway the issue is not that forks can happen (which is inevitable), but that users should know they have happened and be able to deal with them. 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 13:17:46 +0100, "j. v. d. hoff" wrote: > 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, Jan 13, 2013 at 3:52 PM, j. v. d. hoff wrote: > 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 18:48:30 +0100, Stefan Bellon 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, 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] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 5:10 AM, Richard Hipp wrote: > > > On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote: > >> >> >> >> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote: >> >> >> Curious response. Did you intend to be insulting? I'm working with a >> bunch of very smart people >> > > No insult intended. It's the smart people who have the greatest tendency > to go "heads down". I'm sorry that insult was inferred - my fault for > sending a long and ranting post late on a Saturday night. > Ok. Thanks. > who are very reluctantly learning a new tool and a different way of doing >> things and forks are very confusing when they happen in a scenario where >> they seemingly should not. We are not operating in a disconnected fashion >> here. Fossil falls somewhat short in the support of people who like to get >> their job done at the command line (about 80% of users on my team). >> Distilling from the fossil timeline command that there is a fork and how to >> fix it is not easy. It is very tiresome to have to go back to the ui to >> ensure that a fork hasn't magically appeared. >> > > This is the part I don't understand, apparently: Your developers don't > like to use the web interface to see what is happening? One quick glance > at the web timeline would reveal the unintentional fork. > These are busy repos. It sometimes takes me a minute to figure out what is happening so I agree it is most often a quick glance but not always. I'm not sure how to communicate the efficiency some people experience with a cli. Some people like vi, compile, test, examine history etc. all from one or two xterms and indeed I sometimes like this mode also. I personally find it a minor annoyance to have to bring up the ui, possibly because on a daily basis I'm dealing with five or more different fossil areas and keeping track of which ui goes with which task is distracting whereas if I'm working in an xterm with repoX then when I type in "fossil timeline" I know with 100% confidence in zero time that the timeline I'm looking at is for repoX. The ui will pop up another window that must be found in the myriad of windows with chip layout, schematics and other fossil repo ui's etc. already filling my desktop. The Fossil web interface is intended to aid developers in keeping track of what other team members are doing. Is there a reluctance among your people to use this interface? Please help me to understand the source of this reluctance so that I can try to address it. I think the fossil ui doe a great job, it is just the nature of yet another window to deal with that is an issue for some (I'm speculating here but know that this is sometimes true for myself). > >> Anyhow, I misunderstood the exact nature of the cause. I assumed that the >> race condition lay within the users fossil process between the time the db >> query that checked for leaf and the insertion of the new checkin data in to >> the db. That is of course incorrect. The actual cause is that the central >> database is free to receive a commit via sync after having just done a sync >> that informs the users fossil process that it is fine to commit. Something >> like the following: >> >> User1 User2central >> sync >> leafcheck sync >> commit leafcheck >> synccommit receives delta from user1 just fine >> sync receives delta from user2 and now a fork >> exists >> >> As you point out below that is very difficult if not impossible to "fix". >> What I think would alleviate this issue would be a check for fork creation >> at the end of the final sync. If a fork is found notify the user so it can >> be dealt with before confusion is created. >> > > OK. Right now the first sync is really just a pull, and the second is > really just a push. But it is no big deal to change the second to a full > sync. Then, you think it should issue a warning if there is another open > "leaf" on the same branch? > > A quick check shows that this would causes warnings every time we check > into the Fossil trunk, as there are a few abandoned trunk leaves: > >(1) http://www.fossil-scm.org/fossil/timeline?c=4c931047ef >(2) http://www.fossil-scm.org/fossil/timeline?c=b41feab774 >(3) http://www.fossil-scm.org/fossil/timeline?c=9503a9152e > > These leaves would have to be "closed" to silence the warnings. I'm > guessing that every long-running project would have a few abandoned trunk > leaves like this. > > Or, maybe the warning should only complain if the fork involved two > check-ins occurring within a small amount of time of each other? Say, for > example, that the warning only appears if the other leaf is within the > previous 50 commits? > There might be some minor transition pain where a bit of clean up of old repos would be necessary. I personally feel that keeping it simple and encouraging a clean history is good. If you have an old fork in the repo convert it to a branch and annotate
Re: [fossil-users] Unintentional fork/race condition
In my opinion, the solution is more simple. Instead of: - sync - stop if would fork - commit - sync The procedure should be: - commit - sync - rollback if would fork Ramon Ribó El 13/01/2013 13:11, "Richard Hipp" va escriure: > > > On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote: > >> >> >> >> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote: >> >> >> Curious response. Did you intend to be insulting? I'm working with a >> bunch of very smart people >> > > No insult intended. It's the smart people who have the greatest tendency > to go "heads down". I'm sorry that insult was inferred - my fault for > sending a long and ranting post late on a Saturday night. > > > >> who are very reluctantly learning a new tool and a different way of doing >> things and forks are very confusing when they happen in a scenario where >> they seemingly should not. We are not operating in a disconnected fashion >> here. Fossil falls somewhat short in the support of people who like to get >> their job done at the command line (about 80% of users on my team). >> Distilling from the fossil timeline command that there is a fork and how to >> fix it is not easy. It is very tiresome to have to go back to the ui to >> ensure that a fork hasn't magically appeared. >> > > This is the part I don't understand, apparently: Your developers don't > like to use the web interface to see what is happening? One quick glance > at the web timeline would reveal the unintentional fork. > > The Fossil web interface is intended to aid developers in keeping track of > what other team members are doing. Is there a reluctance among your people > to use this interface? Please help me to understand the source of this > reluctance so that I can try to address it. > > >> >> Anyhow, I misunderstood the exact nature of the cause. I assumed that the >> race condition lay within the users fossil process between the time the db >> query that checked for leaf and the insertion of the new checkin data in to >> the db. That is of course incorrect. The actual cause is that the central >> database is free to receive a commit via sync after having just done a sync >> that informs the users fossil process that it is fine to commit. Something >> like the following: >> >> User1 User2central >> sync >> leafcheck sync >> commit leafcheck >> synccommit receives delta from user1 just fine >> sync receives delta from user2 and now a fork >> exists >> >> As you point out below that is very difficult if not impossible to "fix". >> What I think would alleviate this issue would be a check for fork creation >> at the end of the final sync. If a fork is found notify the user so it can >> be dealt with before confusion is created. >> > > OK. Right now the first sync is really just a pull, and the second is > really just a push. But it is no big deal to change the second to a full > sync. Then, you think it should issue a warning if there is another open > "leaf" on the same branch? > > A quick check shows that this would causes warnings every time we check > into the Fossil trunk, as there are a few abandoned trunk leaves: > >(1) http://www.fossil-scm.org/fossil/timeline?c=4c931047ef >(2) http://www.fossil-scm.org/fossil/timeline?c=b41feab774 >(3) http://www.fossil-scm.org/fossil/timeline?c=9503a9152e > > These leaves would have to be "closed" to silence the warnings. I'm > guessing that every long-running project would have a few abandoned trunk > leaves like this. > > Or, maybe the warning should only complain if the fork involved two > check-ins occurring within a small amount of time of each other? Say, for > example, that the warning only appears if the other leaf is within the > previous 50 commits? > > >> >> Just to illustrate, I think monotone deals rather nicely with the natural >> but annoying creation of forks. The user is informed immediately the fork >> occurs. Then the user only has to issue "mtn merge" and it does the easy >> and obvious merge. >> > > Huh. OK - I think I can arrange for "fossil merge" (with no argument) to > merge the most recent other leaf of the current branch, if there is one, > and fail if there is none. Then you can simply type "fossil merge" from > time to time, and if there has been a fork it will be resolved, and if > there is no fork, you will be told and the command will be a no-op. > > > > >> With fossil I have to poll the ui to ensure I don't have a fork, if I do >> have a fork I have to browse the UI and figure out the hash id of the fork, >> do the merge and finally do a commit, manually doing what could probably be >> mostly automated. >> >> Contrast with git where you know when you are causing a fork because you >> do it all the time and dealing with forks is just day to day business. >> Fossil will silently fork and only by starting up the ui and digging around >> will it become apparent that there is a fork. >> >> In the
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
looks good On Sun, 13 Jan 2013 15:42:22 +0100, Stephan Beal wrote: On Sun, Jan 13, 2013 at 3:13 PM, j. v. d. hoff wrote: 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, Jan 13, 2013 at 3:13 PM, j. v. d. hoff wrote: > 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)
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
wrote:
On Sun, Jan 13, 2013 at 2:41 PM, Stephan Beal
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, 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)
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 2013 14:37:38 +0100, Stephan Beal wrote: On Sun, Jan 13, 2013 at 2:16 PM, j. v. d. hoff 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
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
On Sun, Jan 13, 2013 at 2:41 PM, Stephan Beal 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 :/. -- - 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:21:23 +0100, Stefan Bellon wrote: On Sun, 13 Jan, Stephan Beal wrote: stephan@tiny:~/cvs/fossil/fossil$ f stat Repository Statistics: Repository Size: 35969024 bytes (36.0MB) Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta blobs) Uncompressed Artifact Size: 52103 bytes average, 4993770 bytes max, 1015763428 bytes (1.0GB) total Compression Ratio: 28:1 Number Of Check-ins: 4890 Number Of Files: 749 Number Of Wiki Pages: 23 (282 changes) Number Of Tickets: 990 (3137 changes) Duration Of Project: 2003 days or approximately 5.48 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 I like this idea a lot! However I beg for more thinking about the names used in the output. The one thing about fossil I dislike most is the inconsistent naming of switches (double-minus vs. single-minus vs. short) as well as the +1 (Incidentally I did already put that one into the new wiki page http://www.fossil-scm.org/fossil/wiki?name=Wish+List today) inconsistent output of its commands. While this may not be that annoying when using the web it is when using the command line and it is even more when doing script automation using the command line interface. For example the output of "fossil info" (and "status", etc.) is in style project-name: ... project-code: ... whereas after a commit you get the following response New_Version: ... There's a difference in casing and usage of hyphen versus underscore. When I started using fossil I was expecting something like checkout: ... as response from the "commit" command to be in stylistic and terminology sync with the other outputs (especially "status"). Regarding the new "stat" (or "stats"?) command I'd very much like to see it matching the already existing output styles rather than invent a new one: repository-size: ... artifact-count: ... compression-ratio: ... checkin-count: ... file-count: ... wiki-count: ... ticket-count: ... project-uptime: ... project-id: ... server-id: ... fossil-version: ... sqlite-version: ... database-stats: ... Or something similar to that (I'm not suggesting the final names here, just the style to use). I hope you can take that into consideration when implementing the final statistics command. 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 2:21 PM, Stefan Bellon wrote: > one thing about fossil I dislike most is the inconsistent naming of > switches (double-minus vs. single-minus vs. short) BTW: fossil treats -x and --x equivalently. Which one you use is a matter of personal preference. > as well as the > inconsistent output of its commands. That's largely a side effect of so many people having added them :/. > Regarding the new "stat" (or "stats"?) command I'd very much like to > see it matching the already existing output styles rather than invent a > new one: > The current draft is just copy/pasted from the /stat page implementation. i plan on switching to a-b-c notation, like you show here: > repository-size: ... > artifact-count: ... > ...Or something similar to that (I'm not suggesting the final names here, > just the style to use). > and the JSON API provides one way to get at those values in a scriptable format (fine for any language supporting JSON, but not shell scripts). > I hope you can take that into consideration when implementing the final > statistics command. > Yes, of course :). i appreciate your feedback. -- - 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 2:16 PM, j. v. d. hoff 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 mean the idea is rejected, it just means i personally don't like it. > 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 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) 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." -- - 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, Stephan Beal wrote: > stephan@tiny:~/cvs/fossil/fossil$ f stat > Repository Statistics: > Repository Size: 35969024 bytes (36.0MB) > Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta > blobs) Uncompressed Artifact Size: 52103 bytes average, 4993770 bytes > max, 1015763428 bytes (1.0GB) total > Compression Ratio: 28:1 > Number Of Check-ins: 4890 > Number Of Files: 749 > Number Of Wiki Pages: 23 (282 changes) > Number Of Tickets: 990 (3137 changes) > Duration Of Project: 2003 days or approximately 5.48 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 I like this idea a lot! However I beg for more thinking about the names used in the output. The one thing about fossil I dislike most is the inconsistent naming of switches (double-minus vs. single-minus vs. short) as well as the inconsistent output of its commands. While this may not be that annoying when using the web it is when using the command line and it is even more when doing script automation using the command line interface. For example the output of "fossil info" (and "status", etc.) is in style project-name: ... project-code: ... whereas after a commit you get the following response New_Version: ... There's a difference in casing and usage of hyphen versus underscore. When I started using fossil I was expecting something like checkout: ... as response from the "commit" command to be in stylistic and terminology sync with the other outputs (especially "status"). Regarding the new "stat" (or "stats"?) command I'd very much like to see it matching the already existing output styles rather than invent a new one: repository-size: ... artifact-count: ... compression-ratio: ... checkin-count: ... file-count: ... wiki-count: ... ticket-count: ... project-uptime: ... project-id: ... server-id: ... fossil-version: ... sqlite-version: ... database-stats: ... Or something similar to that (I'm not suggesting the final names here, just the style to use). I hope you can take that into consideration when implementing the final statistics command. 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 13:38:45 +0100, Stephan Beal wrote: On Sun, Jan 13, 2013 at 1:20 PM, j. v. d. hoff wrote: why is this? i can't say with certainty - my insight into sqlite's internals is very limited. mine is zero. I do of course see this delay when grepping through the whole timeline (and my initial wish was motivated by the hope that the relevant info is "just there" in the database), but I would have thought the relevant statistics is already in the database. and if not so: why not at a small table containing these statistics? As a general rule (perhaps not consciously) fossil doesn't cache what it can calculate. There are a few instances where it builds an internal temp table as a form of cache, but those are few and far between. We don't (yet?) have a generic mechanism/API for caching in fossil. For this particular calculation, it would be easy for the cache to get out of sync if someone adds a feature which modifies the values it depends on. I was actually thinking about the possibility of adding/augmenting a suitable table either in the repo itself or in .fslckout (the latter probably is more reasonable?), which is brought up-to-date with each new commit/pull/update/sync of the repo (that is maintain a few autoincrementing counters, basically). 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? I could even imagine that this (new?) table could also hold two associative array where the keys(values) are the SHA1 hashes and the values(keys) the chronological revision number if such rev. numbers cannot be fitted easily in the real machinery. such arrays could then be queried to get translate between rev. nums and SHA1 hashes if rel. rev. 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... Here's a first draft, basically the same as the /stat page, reformatted for the console, using the "other" commit count calculation, and adding wiki/ticket change counts: stephan@tiny:~/cvs/fossil/fossil$ f stat --brief Repository Statistics: Repository Size: 35969024 bytes (36.0MB) Duration Of Project: 2003 days or approximately 5.48 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 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. stephan@tiny:~/cvs/fossil/fossil$ f stat Repository Statistics: Repository Size: 35969024 bytes (36.0MB) Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta blobs) Uncompressed Artifact Size: 52103 bytes average, 4993770 bytes max, 1015763428 bytes (1.0GB) total Compression Ratio: 28:1 Number Of Check-ins: 4890 Number Of Files: 749 Number Of Wiki Pages: 23 (282 changes) Number Of Tickets: 990 (3137 changes) Duration Of Project: 2003 days or approximately 5.48 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 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 "brief" flag removes any calculations which tend to grow with the size of the repo - basically anything which requires a non-O(1) query. i should probably(?) change: Number Of Check-ins: 4890 Number Of Files: 749 to: Number Of Files: 749 (4890 commits) 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). 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 Sun, Jan 13, 2013 at 1:20 PM, j. v. d. hoff wrote: > why is this? i can't say with certainty - my insight into sqlite's internals is very limited. > I do of course see this delay when grepping through the whole timeline > (and my initial wish was motivated by the hope that the relevant info is > "just there" in the database), but I would have thought the relevant > statistics is already in the database. and if not so: why not at a small > table containing these statistics? As a general rule (perhaps not consciously) fossil doesn't cache what it can calculate. There are a few instances where it builds an internal temp table as a form of cache, but those are few and far between. We don't (yet?) have a generic mechanism/API for caching in fossil. For this particular calculation, it would be easy for the cache to get out of sync if someone adds a feature which modifies the values it depends on. Here's a first draft, basically the same as the /stat page, reformatted for the console, using the "other" commit count calculation, and adding wiki/ticket change counts: stephan@tiny:~/cvs/fossil/fossil$ f stat --brief Repository Statistics: Repository Size: 35969024 bytes (36.0MB) Duration Of Project: 2003 days or approximately 5.48 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 stephan@tiny:~/cvs/fossil/fossil$ f stat Repository Statistics: Repository Size: 35969024 bytes (36.0MB) Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta blobs) Uncompressed Artifact Size: 52103 bytes average, 4993770 bytes max, 1015763428 bytes (1.0GB) total Compression Ratio: 28:1 Number Of Check-ins: 4890 Number Of Files: 749 Number Of Wiki Pages: 23 (282 changes) Number Of Tickets: 990 (3137 changes) Duration Of Project: 2003 days or approximately 5.48 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 The "brief" flag removes any calculations which tend to grow with the size of the repo - basically anything which requires a non-O(1) query. i should probably(?) change: Number Of Check-ins: 4890 Number Of Files: 749 to: Number Of Files: 749 (4890 commits) :-? -- - 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)
uuhps, hit the send buttom to early: On Sun, 13 Jan 2013 13:06:25 +0100, Stephan Beal wrote: On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal wrote: 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 why is this? I do of course see this delay when grepping through the whole timeline (and my initial wish was motivated by the hope that the relevant info is "just there" in the database), but I would have thought the relevant statistics is already in the database. and if not so: why not at a small table containing these statistics? 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. -- 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 2013 13:06:25 +0100, Stephan Beal wrote: On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal wrote: 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 maybe call it 'dbstat' or whatever in order to avoid the naming collision. 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 ;). 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 ;-) Let me think a bit about this, but i think moving this info into a 'stat' command is the right thing to do. -- 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] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote: > > > > On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote: > > > Curious response. Did you intend to be insulting? I'm working with a bunch > of very smart people > No insult intended. It's the smart people who have the greatest tendency to go "heads down". I'm sorry that insult was inferred - my fault for sending a long and ranting post late on a Saturday night. > who are very reluctantly learning a new tool and a different way of doing > things and forks are very confusing when they happen in a scenario where > they seemingly should not. We are not operating in a disconnected fashion > here. Fossil falls somewhat short in the support of people who like to get > their job done at the command line (about 80% of users on my team). > Distilling from the fossil timeline command that there is a fork and how to > fix it is not easy. It is very tiresome to have to go back to the ui to > ensure that a fork hasn't magically appeared. > This is the part I don't understand, apparently: Your developers don't like to use the web interface to see what is happening? One quick glance at the web timeline would reveal the unintentional fork. The Fossil web interface is intended to aid developers in keeping track of what other team members are doing. Is there a reluctance among your people to use this interface? Please help me to understand the source of this reluctance so that I can try to address it. > > Anyhow, I misunderstood the exact nature of the cause. I assumed that the > race condition lay within the users fossil process between the time the db > query that checked for leaf and the insertion of the new checkin data in to > the db. That is of course incorrect. The actual cause is that the central > database is free to receive a commit via sync after having just done a sync > that informs the users fossil process that it is fine to commit. Something > like the following: > > User1 User2central > sync > leafcheck sync > commit leafcheck > synccommit receives delta from user1 just fine > sync receives delta from user2 and now a fork > exists > > As you point out below that is very difficult if not impossible to "fix". > What I think would alleviate this issue would be a check for fork creation > at the end of the final sync. If a fork is found notify the user so it can > be dealt with before confusion is created. > OK. Right now the first sync is really just a pull, and the second is really just a push. But it is no big deal to change the second to a full sync. Then, you think it should issue a warning if there is another open "leaf" on the same branch? A quick check shows that this would causes warnings every time we check into the Fossil trunk, as there are a few abandoned trunk leaves: (1) http://www.fossil-scm.org/fossil/timeline?c=4c931047ef (2) http://www.fossil-scm.org/fossil/timeline?c=b41feab774 (3) http://www.fossil-scm.org/fossil/timeline?c=9503a9152e These leaves would have to be "closed" to silence the warnings. I'm guessing that every long-running project would have a few abandoned trunk leaves like this. Or, maybe the warning should only complain if the fork involved two check-ins occurring within a small amount of time of each other? Say, for example, that the warning only appears if the other leaf is within the previous 50 commits? > > Just to illustrate, I think monotone deals rather nicely with the natural > but annoying creation of forks. The user is informed immediately the fork > occurs. Then the user only has to issue "mtn merge" and it does the easy > and obvious merge. > Huh. OK - I think I can arrange for "fossil merge" (with no argument) to merge the most recent other leaf of the current branch, if there is one, and fail if there is none. Then you can simply type "fossil merge" from time to time, and if there has been a fork it will be resolved, and if there is no fork, you will be told and the command will be a no-op. > With fossil I have to poll the ui to ensure I don't have a fork, if I do > have a fork I have to browse the UI and figure out the hash id of the fork, > do the merge and finally do a commit, manually doing what could probably be > mostly automated. > > Contrast with git where you know when you are causing a fork because you > do it all the time and dealing with forks is just day to day business. > Fossil will silently fork and only by starting up the ui and digging around > will it become apparent that there is a fork. > > In the referred to message DRH writes: > > DVCSs make it very easy to fork the tree. To listen to > Linus Torvalds you would think this is a good thing. But > experience suggests otherwise. > > I still mostly agree with this, but requiring that every developer poll > the database for forks or risk confusion makes me think that the git > approach is perhaps not so crazy after all.
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
On Sun, 13 Jan 2013 12:58:10 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff
wrote:
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.
ah! bug report: `fossil help timeline' does not say anything about
existence of a `g' type (and further?) types, although it accepts the flag
(and reports 287
entries in the present example).
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
well, I'm not a CS guy: I would catch the `0' immediately after parsing
input and replace it by {some_rediculously_huge_number} just as if I had
entered the huge number in the first place. this would work for the rest
of the lifetime of the universe, probably.
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
of course.
analysis confers with yours - that the current count is not quite correct
or is "correct for some other definition of 'commit'").
which then would seemingly not be in accord with what a user is wanting to
know (namely the number of corresponding timeline entries, right?
many thanks for addressing this issue,
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 Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal wrote: > 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] Unintentional fork/race condition
just my 2 cents: 1. I agree that it should be easier (or occuring even automatically?) to merge such random forks. the `monotone' example was given. `hg' is another obvious one doing that painlessly. 2. I agree that improvement of the CLI is not given enough attention in comparison to the GUI and that is especially difficult (not reall feasible, that is) to keep track of the branch/fork/merge structure of the timeline when solely using the CLI. in this context: some time ago I asked the list whether an 'ASCII art' DAG added to the timeline could be added (as an option, not as default!) which looks like this in `Mercurial': 8< @ changeset: 230:ba70fc98b524 | user:u2 | date:Thu Dec 02 19:33:36 2010 +0100 | summary: inclusion of joe's changes, part 3. | ochangeset: 229:896e4bf421cc |\ parent: 228:b577d53d4484 | | parent: 227:096dd5485186 | | user:u2 | | date:Thu Dec 02 17:43:29 2010 +0100 | | summary: Automated merge with ssh://somehost/somefile | o changeset: 228:b577d53d4484 | | parent: 226:25a0f016d4e5 | | user:u1 | | date:Thu Dec 02 17:15:43 2010 +0100 | | summary: - updated fig.13 | | o | changeset: 227:096dd5485186 |/ user:u2 |date:Thu Dec 02 17:43:24 2010 +0100 |summary: intermediate state | 8< I believe if such a thing were available, even "militant" CLI users would be able to keep track where they are on the graph (`hg' uses the `@' sign for *CURRENT*, by the way) and the reported problem would be less annoying/confusing. doing this is probably somewhat tedious but at least the logic for drawing the graph is already in place and used in the web GUI. so maybe it is feasible in finite time... j. On Sun, 13 Jan 2013 07:45:51 +0100, Matt Welland wrote: On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote: On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland wrote: This is with regards to the problem described here: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html We are seeing on the order of 3-5 of these a year in our heaviest hit repos. While this may seem like no big deal the fact that it is so silent is quite disruptive. The problem is that a developer working intently on a problem may not notice for hours or even days that they are no longer actually working on the main thread of development. I contend that this points up issues with your development process, not with Fossil. If your developers do not notice that a fork has occurred for days, then they are doing "heads down" programming. They are not maintaining situational awareness. ( http://en.wikipedia.org/wiki/Situation_awareness) They are fixating on their own (small) problems and missing the big picture. This can lead dissatisfied customers and/or quality problems. "Situational awareness" is usually studied in dynamic environments that are safety critical, such as aviation and surgery. Loss of situational awareness is a leading cause of airplane crashes and medical errors. Loss of situational awareness is sometimes referred to as "tunnel vision". The person fixates on one tiny aspect of the problem and ignores the much large crisis unfolding around him. Eastern Airlines flight 401 ( http://en.wikipedia.org/wiki/Eastern_Air_Lines_Flight_401) is a classic example of this: All three pilots of an L-1011 where "working intently" on a malfunctioning indicator light to the point that none of them noticed that the plane was losing altitude until seconds before it crashed in the Florida Everglades. Though usually studied in safety critical environments, situational awareness is applicable in any complex and dynamic problem environment, such as a developing advanced software. When you tell me that your developers are "intently working" on one small aspect of the problem, to the point of not noticing for several days that the trunk as forked - that tells me that there are likely other far more serious problems that they are also not noticing. The fork is easily fixed with a merge. The other more serious problems might not have such an easy fix. And they might go undetected until your customer stumbles over them. So, I would use the observation that forks are going undetected as a symptom of more serious process problems in your organization, and encourage you to seek ways of getting your developers to spend more time "heads up" and looking at the big picture. (Did you notice - "situational awareness" is kind of a big issue with me. Fossil is my effort at building a DVCS that does a better job of promoting situational awareness that the other popular VCSes out there. I'm constantly looking for ways to enhance Fossil to promote better situational awareness.
Re: [fossil-users] `fossil info' feature request (a.k.a. wish)
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff wrote: > 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, 13 Jan 2013 11:38:17 +0100, Stephan Beal 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 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 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)
Hiho, On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff 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 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
