On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland <[email protected]> wrote:
> > > > On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp <[email protected]> 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 User2 central > sync > leafcheck sync > commit leafcheck > sync commit 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. > I agree the scanning the timeline to look for forks is a hassle. I will agree to try to fix this. But my broader point is that developers should be scanning the timeline periodically, anyhow, for other reasons, namely to see what other members of the team are doing, to maintain the big picture, and to stay on top of things. Look around. Don't let yourself get into this situation: http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg You do that, and 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). Fair enough? -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
