4 ms·

> [Fossil is] basically incapable of rewriting your development branch into something more logical... False. All you need to do is start a separate "presentat

by SQLite 5y ago

> [Fossil is] basically incapable of rewriting your development branch into something more logical... False. All you need to do is start a separate "presentation branch" and cherrypick and/or merge changes from your "development branch" in as necessary to make it logical for review. Not difficult to do. The difference from Git is that in Git you end up discarding the development branch and keeping only the presentation branch, whereas Fossil preserves them both. Fossil does anything Git will do, except for one thing: Fossil does not (easily) sync individual branches. (You can do it, but it is a pain.) Git comes with the idea that individual developers keep their own private branches and only share them after they've been cleaned up. The idea behind Fossil is that everybody shares everything. By analogy: Git is like where everybody has their own office with doors that close, and developers emerge from their own office from time to time to share their work or collaborate. Fossil is more like an open office with no walls or doors. There are advantages and disadvantages to both approaches. I encourage you to use whichever one works best for you. If you like the Git approach, then by all means use Git. I find that the Fossil approach works better on the projects that I manage, but that just me. You do whatever works best for you. Bottom line: Fossil was created to support SQLite development. It does this very, very well. If it never does anything else, it will have been a great success. Any use of Fossil beyond SQLite is just gravy. As it turns out, many other developers have found Fossil useful, too. But perhaps your usage patterns are different and the Fossil model does not work for you. That does not invalidate the fact that it works well for others. All that said, there are many ideas in Fossil that could be copied into Git without changing the Git development model. So even if you don't like Fossil's development model, you should still look at Fossil, so that you can steal ideas (and/or source code) to import into Git and hence make Git better.

deleted 5y ago
[deleted]
gwd 5y ago
> Bottom line: Fossil was created to support SQLite development. It does this very, very well. ...But perhaps your usage patterns are different and the Fossil model does not work for you. That does not invalidate the fact that it works well for others. So first, let me reiterate that SQLite is awesome; you and your team have probably had a larger positive impact on the world per man hour of coding than any software project in the history of the world. You've already given us an amazing self-contained database system; I'm hardly in a position to demand that you write me a version control system as well. Secondly, when I wrote "this could only be written by", I was really mixing up the linked text with another article on your website, "Rebase considered harmful" [1], which is far more opinionated. I'm sorry for getting that slightly mixed up; but only slightly sorry, since the "original designer of Fossil" wrote both; I understand that person to be you. [1] https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I didn't actually say anything bad about Fossil or that it wasn't a useful system. What I did say was that presenting a change as a series of chunks presented in a logical order, targeted at easy reviewing, is necessary for a large project. I stand beside that assessment. > Git comes with the idea that individual developers keep their own private branches and only share them after they've been cleaned up. The idea behind Fossil is that everybody shares everything. And I can't see how this is remotely sustainable for a large project, or a project hoping for "drive-by" contributions. I understand SQLite to be developed by 4 people or so, who have worked closely together for years; I can see where having every development branch of every developer would be an advantage in your case. And since you don't generally accept external contributions (as I understand it), "drive-by" contributions aren't a consideration. The previous release of my project, which represented only 8 months of development, had changesets from 61 different people; and we frequently get submissions from people who just have a single fix or a single feature they wanted to add, after which we never hear from them again. I can't imagine having every version of every development branch of every person who'd ever contributed to the project (or thought about contributing to the project) in the project log. > By analogy: Git is like where everybody has their own office with doors that close, and developers emerge from their own office from time to time to share their work or collaborate. Fossil is more like an open office with no walls or doors. Git was designed so that thousands of people in different workshops and in different towns could come together in an ad-hoc fashion to share what they'd been doing. Having four people working together in the same keycarded space sounds nice; but having thousands of people in one gigantic gym sounds like pandemonium, and having the doors open so anyone can walk in and start vandalizing the place is unworkable. > False. All you need to do is start a separate "presentation branch" and cherrypick and/or merge changes from your "development branch" in as necessary to make it logical for review. Not difficult to do. And if you need to iterate over that "presentation branch"? Do you make a new "presentation branch" every time you realize some change from patch A would logically go better in patch B or vice versa? Is the final version of the presentation branch automatically linked to the intermediate presentation branches, and the original development branch(es)? In your documentation you seem to be aware that Fossil will "nudge" developers in certain directions -- including "nudging" people to delay checking in changes (e.g., before proper testing). Don't you think having all these previous versions dangling around will "nudge" developers into doing fewer iterations of their "presentation branch", resulting in a branch which is more difficult to review and/or do archaeology on? Don't you think the delaying of check-in, in particular with the knowledge that what you've done will be seen, will negatively affect the way people develop? I mean, I don't inherently have a problem with keeping all my random development stuff locally. git actually does keep all your old commits around when you do a rebase -- they're just not linked anywhere, and they get garbage collected occasionally. (There's no reason someone couldn't build a porcelain on git to make branches for those commits and link them in the comments.) But I wouldn't to have to manually hide all those branches -- I'd want them to disappear by default, as they do with git, unless I actively look for them. Having them not disappear would nudge me in a direction I don't want to go. And as a maintainer of an open-source project I don't want random people on the internet sending me all of the development versions of their patches; I want to see the actual change they're proposing to make to my project, and nothing else. I'm willing to accept that I maybe I just don't understand how your model works; and if I did I'd be less skeptical of it. But having read [1], I'm quite sure you don't understand how my model works, or you wouldn't say it "has no offsetting benefits".

by SQLite 5y ago

deleted 5y ago

[deleted]

gwd 5y ago

> Bottom line: Fossil was created to support SQLite development. It does this very, very well. ...But perhaps your usage patterns are different and the Fossil model does not work for you. That does not invalidate the fact that it works well for others. So first, let me reiterate that SQLite is awesome; you and your team have probably had a larger positive impact on the world per man hour of coding than any software project in the history of the world. You've already given us an amazing self-contained database system; I'm hardly in a position to demand that you write me a version control system as well. Secondly, when I wrote "this could only be written by", I was really mixing up the linked text with another article on your website, "Rebase considered harmful" [1], which is far more opinionated. I'm sorry for getting that slightly mixed up; but only slightly sorry, since the "original designer of Fossil" wrote both; I understand that person to be you. [1] https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md I didn't actually say anything bad about Fossil or that it wasn't a useful system. What I did say was that presenting a change as a series of chunks presented in a logical order, targeted at easy reviewing, is necessary for a large project. I stand beside that assessment. > Git comes with the idea that individual developers keep their own private branches and only share them after they've been cleaned up. The idea behind Fossil is that everybody shares everything. And I can't see how this is remotely sustainable for a large project, or a project hoping for "drive-by" contributions. I understand SQLite to be developed by 4 people or so, who have worked closely together for years; I can see where having every development branch of every developer would be an advantage in your case. And since you don't generally accept external contributions (as I understand it), "drive-by" contributions aren't a consideration. The previous release of my project, which represented only 8 months of development, had changesets from 61 different people; and we frequently get submissions from people who just have a single fix or a single feature they wanted to add, after which we never hear from them again. I can't imagine having every version of every development branch of every person who'd ever contributed to the project (or thought about contributing to the project) in the project log. > By analogy: Git is like where everybody has their own office with doors that close, and developers emerge from their own office from time to time to share their work or collaborate. Fossil is more like an open office with no walls or doors. Git was designed so that thousands of people in different workshops and in different towns could come together in an ad-hoc fashion to share what they'd been doing. Having four people working together in the same keycarded space sounds nice; but having thousands of people in one gigantic gym sounds like pandemonium, and having the doors open so anyone can walk in and start vandalizing the place is unworkable. > False. All you need to do is start a separate "presentation branch" and cherrypick and/or merge changes from your "development branch" in as necessary to make it logical for review. Not difficult to do. And if you need to iterate over that "presentation branch"? Do you make a new "presentation branch" every time you realize some change from patch A would logically go better in patch B or vice versa? Is the final version of the presentation branch automatically linked to the intermediate presentation branches, and the original development branch(es)? In your documentation you seem to be aware that Fossil will "nudge" developers in certain directions -- including "nudging" people to delay checking in changes (e.g., before proper testing). Don't you think having all these previous versions dangling around will "nudge" developers into doing fewer iterations of their "presentation branch", resulting in a branch which is more difficult to review and/or do archaeology on? Don't you think the delaying of check-in, in particular with the knowledge that what you've done will be seen, will negatively affect the way people develop? I mean, I don't inherently have a problem with keeping all my random development stuff locally. git actually does keep all your old commits around when you do a rebase -- they're just not linked anywhere, and they get garbage collected occasionally. (There's no reason someone couldn't build a porcelain on git to make branches for those commits and link them in the comments.) But I wouldn't to have to manually hide all those branches -- I'd want them to disappear by default, as they do with git, unless I actively look for them. Having them not disappear would nudge me in a direction I don't want to go. And as a maintainer of an open-source project I don't want random people on the internet sending me all of the development versions of their patches; I want to see the actual change they're proposing to make to my project, and nothing else. I'm willing to accept that I maybe I just don't understand how your model works; and if I did I'd be less skeptical of it. But having read [1], I'm quite sure you don't understand how my model works, or you wouldn't say it "has no offsetting benefits".