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" <[email protected]> va escriure: > > > 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 > >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
