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] 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] 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] 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] 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
[fossil-users] Unintentional fork/race condition
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. We added the fork detection code to the fossil wrapper which helps (we also see forks due to time lag on syncing between remote sites) but it is still a rather annoying problem. My question is can this be solved by wrapping the code that determines that we are at a leaf and the code that does the final commit with a BEGIN IMMEDIATE; ... END;? This increases the risk of leaving the db in a locked state so having a fossil command to unlock a database would be nice. In this same vein it would be very nice to be able to control the sqlite3 timeout. I'm fairly sure that a longer timeout would give us much better behaviour in our usage model. I have some scripting that can generate the forks and I'm willing to take a stab at making this change but wanted to hear from the list if this solution was worth trying. ___ 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 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 promote better situational awareness. Suggestions are welcomed.) We added the fork detection code to the fossil wrapper which helps (we also see forks due to time lag on syncing between remote sites) but it is still a rather annoying problem. My question is can this be solved by wrapping the code that determines that we are at a leaf and the code that does the final commit with a BEGIN IMMEDIATE; ... END;? No. Fossil already does that. Has done so for years. The problem is that there are multiple disconnected replica of the database. You cannot (reasonably) lock them all. See http://en.wikipedia.org/wiki/CAP_theorem - DVCSes like Fossil choose availability and partition tolerance and the expense of (immediate) consistency, since consistency is easily restored later by merging in the rare event where it doesn't work out straight away. To fix this problem (and again - I'm not yet convinced that it is a problem that needs fixing) I think what you would need to do is create some kind of reservation system for commits. Suppose user A and user B both are about to commit. Each local fossil sends a message to the central repository that tries to reserve the tip of trunk for some limited period of time, say 60 seconds. (The reservation interval might need to be adjusted depending on network latencies). The first reservation wins. If user B is second, he gets back an error that says User A is also trying to commit - wait 60 seconds and try again. That gives user B an opportunity to go for coffee, then merge in user A's changes before he tries again later. You can make a reasonable argument that this is a good approach to development. In terms of the CAP theorem, you are selecting CP rather than the current AP. Of course, this fix doesn't really work if you try to do a commit while off network, since then you cannot make a reservation. It also doesn't work if you don't have a single central repository that everybody commits to. So it isn't for everybody. But I can understand how some organizations would want this. This increases the risk of leaving the
Re: [fossil-users] Unintentional fork/race condition
on Jan 12, 2013, Richard Hipp d...@sqlite.org wrote: On Sat, Jan 12, 2013 at 7:31 PM, Richard Hipp d...@sqlite.org wrote: Loss of situational awareness is a leading cause of airplane crashes and medical errors. Here's another example of loss of situational awareness, which seems likely to result in an adverse outcome: http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg Love it. ^K -- 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 Sat, 12 Jan 2013 19:31:26 -0500 Richard Hipp d...@sqlite.org wrote: 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. If this is the case, I whould suggest better solution. Only 3..5 cases in a year are not enough to train the team enough and to increase the situation awareness of the people. Isn't it better to make fossil to fork randomly with probability, let say, 1:20. This approach will train the users very quick. They will acquire good habits and will never allow airplain crashes and medical errors because of situation awareness loss. -- John Found http://asm32.hopto.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 01/12/2013 09:22 PM, John Found wrote: If this is the case, I whould suggest better solution. Only 3..5 cases in a year are not enough to train the team enough and to increase the situation awareness of the people. Isn't it better to make fossil to fork randomly with probability, let say, 1:20. This approach will train the users very quick. They will acquire good habits and will never allow airplain crashes and medical errors because of situation awareness loss. Please stop trolling -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ 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 Sat, 12 Jan 2013 21:22:28 -0800 Michael L. Barrow mlbar...@barrow.me wrote: Please stop trolling I am not trolling. It is Reductio ad absurdum that proves D. Richard Hipp is wrong in his statement. Solving technical problems by high-handed methods is wrong by definition. -- John Found http://asm32.hopto.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 01/12/2013 09:48 PM, John Found wrote: I am not trolling. It is Reductio ad absurdum that proves D. Richard Hipp is wrong in his statement. Solving technical problems by high-handed methods is wrong by definition. The source is available, so you should feel free to download and add in the random fork feature you described. Enjoy! -- Michael Barrow michael at barrow dot me +1 (408) 782-4249 ___ 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 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 promote better situational awareness. Suggestions are welcomed.) Curious response. Did you intend to be insulting? I'm working with a bunch of very smart people 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. 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. 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. With fossil I have to poll the ui to ensure I don't have a fork, if I do have
