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] 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 estifo...@gmail.com wrote: On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland estifo...@gmail.com 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
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] 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 d...@sqlite.org va escriure: On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland estifo...@gmail.com wrote: On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org 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
Re: [fossil-users] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 5:10 AM, Richard Hipp d...@sqlite.org wrote: On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland estifo...@gmail.com wrote: On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp d...@sqlite.org 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 appropriately. Using a heuristic such as the last 50 commits is sure to
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] Unintentional fork/race condition
On Sun, 13 Jan 2013 16:35:11 +0100, Ramon Ribó ram...@compassis.com 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 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] Unintentional fork/race condition
On Sun, 13 Jan 2013 07:48:59 +0200, John Found johnfo...@evrocom.net wrote: On Sat, 12 Jan 2013 21:22:28 -0800 Michael L. Barrow mlbar...@barrow.me 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 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] Unintentional fork/race condition
On Sun, 13 Jan 2013 20:36:50 +0100, Ramon Ribó ram...@compassis.com 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] Unintentional fork/race condition
On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp d...@sqlite.org 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, Jan 13, 2013 at 6:58 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp d...@sqlite.org 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
