On Fri, Apr 17, 2015 at 10:12 AM, Ron W <ronw.m...@gmail.com> wrote: > On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger < > jo...@britannica.bec.de> wrote: > >> As discussed earlier, a fork means more than one >> leaf for the same branch. > > > And merging the leaf of a branch to another branch (maybe trunk) does not > make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever > make the "fork-leaf" not a "fork"? >
Is this a conversation about the pragmatic aspects of a same-named split in a timeline (the fossil working definition of fork) or about some abstract philosophical semantics? For fossil to be a viable long term solution in a intensely busy project I believe the following is needed: 1. The optimal solution, where possible, don't let forks happen at all. Git does this at a very slight cost to data safety. 2. Aggressively keep users informed of any open forks in the timeline 3. No false warnings. #1 won't happen due to fossil emphasis on data safety, I believe it *can* be done for the common use case of an autosync commit. #2 is in progress but not aggressive enough to address my concern (thanks Andy and Jan for your efforts, much appreciated) #3 was looking problematic, possibly due to philosophy trumping pragmatism? Might be addressed now? I have tested the changes from trunk and Andy's fork-warn branch and I'm not seeing the kind of warnings that would catch the attention of a busy developer and prompt him or her to merge or close a lingering open fork. fossil update - yes, good warning if you are on the branch with the fork fossil co - no warning fossil status - no warning fossil update <someotherbranch> - no warning Emphasis: there is no known valid need for an ongoing, open, same-named (i.e. "fork") branch. In real-world development I've seen these forks cause wasted time and effort that does NOT contribute to a feeling of goodwill toward fossil. Remember: an open fork is potentially orphaned code that the developer believes is not orphaned! Here is a recent event that solidified my views on forks. I met a friend for lunch who had worked on our team and used fossil. He moved to another team where they were struggling with git. I asked the obvious question "would you consider fossil?" He asked, "did they fix the fork problem?" to which of course I had to reply "no". For him the bad taste of dealing with a fork trumped the pain of ramping up on git which I have to admit made me re-evaluate my "forks are no big deal" view. One more time; a busy developer focused on getting out a release is going to be taken out of the zone and will waste time when a fork happens. The "situation" is the code and the release, polling the timeline to be sure a fork didn't happen for "situational awareness" is a dilution of effort toward the release. > > _______________________________________________ > 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
