Re: [fossil-users] terminology confusion
github calling the project clone maintained on the server side a fork (I believe that's what it is, right?). 100% correct; a Github fork is a server-side clone. A Github fork is also part of the project fork network. This membership allows you to propose changes from your copy of the project to another repository copy in the network - this is the pull request. Normally you propose changes to the initial upstream repository from which you forked, but you can also generate pull requests from your fork to any other repo in the fork network. -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
Fossil simply defines it: Having more than one leaf in the check-in DAG is called a fork. After re-reading the wiki section that you pointed out I have a much better understanding of how Fossil defines a fork. Thanks for pointing that out. What I'm surprised at, after following both discussions, is I don't recall seeing this mentioned, but perhaps it was: *Fork* A fork is when a check-in has two or more direct (non-merge) children in the same branch. And then the example text: Check-in 2 of figure 3 is considered a fork because it has two children in the same branch. Check-in 2 of figure 5 also has two children, but each child is in a different branch, hence in figure 5, check-in 2 is considered a branch point. Figure 3: https://www.fossil-scm.org/index.html/doc/trunk/www/branch03.gif Figure 5: https://www.fossil-scm.org/index.html/doc/trunk/www/branch05.gif My interpretation of fork was an unmerged leaf on the same branch - which is incorrect, according to the docs. This was also the reason I suggested head as a Mercurial analog. In the oft cited example of a fork in 2015 (which happens to be related to my check-in submitted by bundle export/import). My check-in is not actually the fork; the parent of my check-in is the fork. To use Ron's road analogy, if I am driving a car and I come to a fork in the road I can go left or right or however many road choices I have. The fork is the point at which I make a choice. Whichever road I choose, I drive through the fork/branch point and I am now just on a road - maybe the road ends quickly (leaf), maybe it keeps going (branch). The distinction between fork and branch point then becomes important as it gets to intent. *Branch Point* A branch point occurs when a check-in has two or more direct (non-merge) children in different branches. A branch point is similar to a fork, except that the children are in different branches. So a leaf is never a fork; it is just a leaf. Sorry if am restating what was obvious to everyone else. -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
Thus said j. van den hoff on Fri, 17 Apr 2015 07:51:26 +0200: but if changing the terminology really is a seriously considered issue, than I cannot abstain from proposing shoot instead (which would open the theoretical possibility to indicate it as `SHOOT!' in the CLI timeline display -- which most of the time, would be correct, too ;-) If we're looking for a new term, then I propose ``aerial root'' because they're cool: http://commons.wikimedia.org/wiki/File:Aerial_roots_Banyan_Tree_Park.jpg Thanks, Andy -- TAI64 timestamp: 400055312be5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
Mercurial would call a Fossil fork a head[1]. -J [1]: http://mercurial.selenic.com/wiki/MultipleHeads On Thu, Apr 16, 2015 at 12:49 PM, Ron W ronw.m...@gmail.com wrote: As the flurry of discussion of forks starts to ebb, it occurred to me there is a conflict between how Fossil defines fork and how many open source project define fork. Fossil defines fork as an accidental, unintended branch in the commit history. But, to many in the open source community (and other SW development communities), a fork is an intentional split from the commit history to either create a development branch or to create a new project from an existing one. Example: Devuan Linux is a fork of Debian Linux (in contrast to Ubuntu, which is (was?) a down stream derivative of Debian). Also, there's the much older fork in the road, referring a connected road going in a different direction. Unfortunately, I had no luck finding any better term for what Fossil calls a fork. (My search-fu maybe off this morning.) ___ 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
Re: [fossil-users] terminology confusion
On Thu, Apr 16, 2015 at 1:30 PM, James Moger james.mo...@gmail.com wrote: Mercurial would call a Fossil fork a head[1]. -J [1]: http://mercurial.selenic.com/wiki/MultipleHeads That would be what Fossil calls a Leaf. I suppose, one could argue that, in Fossil, a fork is a special case of a leaf, but I consider it to be an accidental, unnamed branch (allowing for the possibility of descendants of the original fork commit). So, in absence of an alternative, in Mercuial, a fork would be an accidental head or accidental branch. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
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, 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. 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
On Thu, Apr 16, 2015 at 1:27 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford amb-fos...@bradfords.org wrote: This document contains what Fossil considers a fork: https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki Yes. And the _connotation_ of the term fork within the Fossil community is unintended/accidental commit to a parent commit with other child commits. My point is that Fossil uses the term fork differently from many other many other open source projects. Examples: Devuan is a fork of Debian, Inkscape is a fork of Sodapodi, etc. Or, how Github uses it to mean a contributor's clone. Some thoughts: If a unique term is required, how about calling an undesirable branch a twig. ;) 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. Mind you, forking in a github sense doesn't have to mean project branch with future pull requests though obviously that's how they intend it. A github fork is really just a heavyweight branch, and until github was launched in 2008 (assuming their fork functionality was an original concept introduced at launch) no one in the world used fork in this sense. Looking at the list of DVCS projects on Wikipedia, it means every notable DVCS was introduced prior to that usage (except for Veracity, which is apparently / arguably dead anyway). I don't think github's success devolves on anyone else to change their terminology any more than I think git's success means that everyone should adopt their confusing hodge podge mass of commands options. In fact, from this point of view, github redefining terminology is unsurprising given how I feel about git's use of terminology in places. Given the traditional meaning of fork (an undesirable branch of development that, if allowed to remain, limits future development options in some way), I don't see that there is a real problem continuing to use the term fork. Introducing a new non-obvious term just so there is distinct separation between fossil forks and github forks seems to only complicate the understanding of fossil. Note that undesirable branch of development could apply to how fossil uses fork, or how github might use fork in the case that the original project never pulls anything back so the two projects diverge, or how BSDs or emacs/xemacs forked deliberately. 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). :) 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. Or we just continue to document what we mean when we use the term fork (perhaps providing the extra text two leaves on the same branch or some such when a fork warning is generated) and continue to provide the existing tools to merge or rename. -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
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
Re: [fossil-users] terminology confusion
Thus said Ron W on Thu, 16 Apr 2015 15:27:38 -0400: So I don't know of an alternative term already in use to suggest. Not can I think of any other alternative term to suggest. I don't know of an alternative either; perhaps a duplicate descendant line. Fossil simply defines it: Having more than one leaf in the check-in DAG is called a fork. I've often thought Git's ``fork'' to be used incorrectly when what really happened was a clone, which is like a fork, but really, it's more like a clone. :-) Andy -- TAI64 timestamp: 40005530218e ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford amb-fos...@bradfords.org wrote: This document contains what Fossil considers a fork: https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki Yes. And the _connotation_ of the term fork within the Fossil community is unintended/accidental commit to a parent commit with other child commits. My point is that Fossil uses the term fork differently from many other many other open source projects. Examples: Devuan is a fork of Debian, Inkscape is a fork of Sodapodi, etc. Or, how Github uses it to mean a contributor's clone. Unfortunately, other DVCs don't seem to have a name for these accidental commits/branches, other than, for example (in Hg), accidental head. So I don't know of an alternative term already in use to suggest. Not can I think of any other alternative term to suggest. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
On Thu, 16 Apr 2015 22:58:55 +0200, 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, 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. 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. personally, I don't see a problem with calling such random branches a fork within the fossil context. but I agree that the use/meaning is a bit idiosyncratic in view of the existence of 'project forks' and (unfortunately) github calling the project clone maintained on the server side a fork (I believe that's what it is, right?). semantically, it might be stated that fork somewhat breaks the tree paradigm (trunk, branch, leave...) or at least introduces a topological property where otherwise components are used. so the suggestion to change to twig might really be a good thing. but if changing the terminology really is a seriously considered issue, than I cannot abstain from proposing shoot instead (which would open the theoretical possibility to indicate it as `SHOOT!' in the CLI timeline display -- which most of the time, would be correct, too ;-) but seriously: maybe all is good and well already ... -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] terminology confusion
Thus said Ron W on Thu, 16 Apr 2015 12:49:43 -0400: Unfortunately, I had no luck finding any better term for what Fossil calls a fork. (My search-fu maybe off this morning.) This document contains what Fossil considers a fork: https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki Scroll to the Forking Versus Branching header. Thanks, Andy -- TAI64 timestamp: 400055300276 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
