On Thu, Apr 16, 2015 at 2:58 PM, Ron W <ronw.m...@gmail.com> wrote: > On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison <sc...@casaderobison.com> > wrote: >> >> Some thoughts: >> >> More seriously, the Wikipedia article on forking is probably worth a >> read: http://en.wikipedia.org/wiki/Fork_(software_development) >> >> I would claim that github is the odd man out here, having appropriated a >> term that historically meant something undesirable and changing it into an >> intended desirable part of the software development process. >> > > Certainly, Github's use of "fork" is different that saying "Devuan" is a > fork of "Debian". > > As to whether a fork is undesirable depends on point of view. I am > willfully ignorant regarding the Debian people's opinions of Devuan. I > will, however, admit that I think the Inkscape fork of Sodapodi benefited > me, >
I'd never heard of Devuan before today. I am familiar with the other examples quoted from ESR: "Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs <http://en.wikipedia.org/wiki/GNU_Emacs>/XEmacs <http://en.wikipedia.org/wiki/XEmacs> split, the fissioning of the386BSD <http://en.wikipedia.org/wiki/386BSD> group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore." It's not that no one benefits from a traditional project fork. Someone must or no one would ever go to the effort. But they often come at a high price in hours spent keeping up with the other project, or incompatible drift between two projects which is potentially hard on the community. Even though there are benefits to the "project fork" there are also undesirable side effects. Pros & Cons. In the case of the "branch fork" that fossil describes, the negative is the time it takes to merge the two back into one branch, or to rename one of the forks so that it becomes its own branch. Certainly learning about forks as early as possible so that they can be addressed appropriately is beneficial to a project. Maybe calling it a "branch fork" or "forked branch" might be adequate terminology. > Accidental head or accidental branch don't seem to apply if for no other >> reason a fork *can* be deliberate. That's not the norm but --allow-fork >> does exist as an option for those cases when fossil can detect a fork will >> happen but to allow it anyway. I suspect most people don't type >> --allow-fork accidentally (when they type it at all). :) >> > > In my experience, a "fork" results when I or one of my teammates forgets > to start a new branch. So, from our perspective, "accidental" is very > applicable. Even with "fossil forks", such an undistinguished "branch" > would be easy to loose track of. I would not want to create a "fork". > Agreed, a deliberate fork would likely be quite rare. I was only saying it is possible so "accidental branch" is not perfectly descriptive. > So, if we *must* have a unique term, I'd vote for twig as I've never heard >> it used in a dvcs context and can't find such a reference via Google. Mind >> you, if we started using twig there is nothing to stop github (or others) >> from coming along and appropriating the terminology, so we could wind up >> right back in this position seven years down the road. >> > > I'm not saying _must_. I only want to point out that it could be a > non-trivial obstacle to adoption for Fossil for some people. > Sorry, I should have included a smiley in there somewhere. While part of me does like the idea of using twig as a term somewhere just because it's amusing, I did mean it tongue in cheek. I still think "fork" is the right term. Fossil's use of it predates the later redefinition by github. The software development industry use of it predates github. If anything, change displayed instances of "fork" to "forked branch" or "fork [two leaves on the same branch]". In fact, as I think more about it, "forked branch" would be sufficiently clear that it's not a github fork (a "forked project" if you will) while alerting the person reading the text that something different from the normal flow has occurred. Assuming they read it at all, anyway. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
