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 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? > 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 fail for someone sometime. That said I'd be thrilled with either solution. > > >> >> 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. > This would be very handy I think and I would obviously like it. We would like the developers energy to be devoted to things of importance and merging an accidental fork is a (admittedly minor) distraction. > > > > >> 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? > Heh heh, sure. Sounds good. Thanks for taking a deeper look at this. I personally love how fossil makes my life easy 98% of the time. It is always that last few percent that is not so easy to tackle. > > -- > 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
