5 ms·

Original author of Fossil here, with two comments: (1) Fossil was created for the single purpose of supporting SQLite development, a mission at which it has su

by SQLite 10y ago

Original author of Fossil here, with two comments: (1) Fossil was created for the single purpose of supporting SQLite development, a mission at which it has succeeded spectacularly. Fossil is therefore a success story, irregardless of its mind-share relative to Git. That thousands of other developers also find Fossil useful on their own project is just gravy. I am not concerned that Fossil has not (yet) become the "one true and great DVCS". My intent is to continue personally supporting and maintaining Fossil for at least three more decades. (2) Git people: Please steal ideas and code from Fossil. This is not about winning and losing; it is about providing the best possible tools. Fossil has a number features which are missing from Git but which could be easily added to Git and would enhance the Git-user experience. I'm not talking about the philosophical differences between Fossil and Git (which I recognize that Git is unlikely to ever change) but rather specific UI features such as "fossil all" or "fossil ui" or "fossil undo" or the ability to view the ancestors of check-ins. Fossil is 2-clause BSD, so you do not even have to acknowledge where you stole the code from. Do it for your users, please.

mysterydip 10y ago
Never heard of it before, but I'm grateful to hear about it! My projects were always small enough that a traditional version control system wasn't worth the time to set up. Just keep an archive of each day's progress in a folder and call it done. With my latest project, I'm maintaining multiple splits of the codebase for different platform-specific features, and sharing the code with a team member. I was about to bite the bullet and start installing cvs or git in a VM and going through the learning curve, but this seems right up my alley and the kind of system I'd mesh with well. Thanks!
- lucaspiller 10y ago
  > My projects were always small enough that a traditional version control system wasn't worth the time to set up There's no such thing as too small: I use Git for everything, including small scripts I may never use again. The setup is "mkdir fooscript && cd fooscript && git init". Plus using GitLuBucket means free backups.
  - splitbrain 10y ago
    What is GitLuBucket? Google thinks you meant BitBucket, but it seems to be a very weird typo.
    - lucaspiller 10y ago
      GitHub/GitLab/BitBucket. Sorry it wasn't clear :-)
- petre 10y ago
  It's really easy to use and it has builtin help like mercurial. No need to read man pages. We use it for all our projects. I also use it for tracking config changes in /etc.
- pablasso 10y ago
  How is `git init` or `hg init` harder than maintaining different versions of your code in separate folders?
  - Moru 10y ago
    It's usually the extra learning curve to use those commands in the first place, not that they are simple to use.
carterehsmith 10y ago
The fact that you created both an SCM, and a RDBMS, kind of forces the question: Does Fossil have something like 'rollback'? If not, would it not be good to have your standard SQL COMMIT/ROLLBACK semantics in an SCM? I mean, sometimes you do something with your SCM that you immediately regret. Like, you do a 'pull' expecting that perhaps a couple files will be changed, and instead you get a screenful of statuses, errors and whatnots. Ooops! So you look at what you typed, and turns out you were in a wrong branch, or you should have used 'pull x y' or whatever. In any case, what you want to do now, is to 'roll back' ('undo') the last command. Now, in SQL, when you make a mistake, you say 'rollback' and everything is good. But in a typical SCM, either you cannot do it at all, or it is nontrivial. E.g. in Git, the way to 'undo' depends on the command that you are undoing. Sometimes it is 'revert', sometimes 'reset ^XX~xx' or 'abort', etc etc, clearly not optimal. Is there an SCM that does that?
- isxek 10y ago
  Mercurial has a 'rollback' command, which they've marked as deprecated a few months (years?) ago, but you can still use it when you reach a tight spot.
  - carterehsmith 10y ago
    Thanks, that's interesting. Hmm, reading about it, it looks like Mercurial's rollback "can be dangerous". That's kind of opposite of what you expect rollback to be.
    - e12e 10y ago
      In a vcs it seems natural that rollback is dangerous - it should be the only way to delete work? The only alternative would be to stash what is rolled back in a branch, or somewhere else on disk? At witch point it isn't really a rollback anymore? Aside from that, I think all major vcs will allow you to clone "up to revision N" which in turn will give you a new repository that has been rolled back to N?
      - 10y ago
i_feel_great 10y ago
"My intent is to continue personally supporting and maintaining Fossil for at least three more decades." Good to hear. This instill confidence in me for my continued use of both Fossil and the reason for its existence, SQLite. Thank you.
e12e 10y ago
I had hoped to use Fossil for a new class I'm teaching, but ended up using a combination of gogs (and git). The web UI is great, and the bundled wiki/bug tracking works fine - but I never could get anonymous push/user registration to work smoothly enough for my needs (we're on a LAN, currently with bring-your-own-device and no central ldap/ad etc). If it wasn't a group of 27 complete beginners (on Windows), I might have started people out with the basics of ssh and key generation - but in the end gogs had an easier start-up: single binary for me to deploy on a server, and git and vscode available for Windows via http://scoop.sh http://scoop.sh (as is Fossil :-)). In the end things worked out - we spent more time on work process, the usual fight with git for a sane workflow (mercurial, Fossil and gitless all make it a bit easier to clone/branch/merge/push than git does. I really don't want too think to much when I rebase, and I don't want to detach my head). The upside is that gogs is closer to the git/github workflow with git as the vcs tool and Web based "pull requests" -- which for better or worse has become standard. And it became an opportunity to show that project management really is about people, communication, cooperation and process - not the tools.
- SQLite 10y ago
  > I never could get anonymous push/user registration to work smoothly.... We are always trying to make Fossil better. Can you explain what you mean by "anonymous push/user registeration" and provide more information on why it was a problem for you? Private email to drh@sqlite.org is ok for this.
  - e12e 10y ago
    The easiest way to explain this is probably through my scenario (and an example of how gogs worked, where Fossil fell a little short): I have 26 students, for whom I have no account information or central auth server (eg a typical "pop-up" workshop). As everyone is new to programming and (d)Vcs, I would prefer some authorization help from the system (Fossil is pretty good here, afaik "git push --force" isn't really an issue). Everyone are on Windows, and while ssh is available, it's not a great fit for the platform. Fossil has "fossil gui" and "fossil serve" which allow users to clone - but I never could get either: plain http (no ssl, as this isn't a public ip which complicates settling up a trusted cert a bit) with push from clients to work - with or without password. With gogs, I could turn off the CAPTCHA and enable registration in the Web ui, and users could push with auth from git and visual studio code, using user/passwords. As far as I got with Fossil was registering users that worked with the Web ui (eg: edit wiki) -- but I couldn't get sync (push to the server) to work (neither from Linux, nor Windows). At first I thought it was an issue with a mix of Fossil versions, but in the end I think that ad-hoc LAN deployments just isn't all that we'll tested? Perhaps especially on/with Windows clients? As far as I gather when cloning a repo, Fossil is supposed to get a copy of the user database, and so everyone should be able to a) use "fossil gui" and edit wiki pages etc and have changes auto-sync out of the box (assuming the upstream Fossil instance is up) and b) use "fossil serve" and have other registered users be able to push changes? I was able to pull, and sync/push over ssh, but (auto)sync over http always failed. From the docs, it looks like it is supposed work, with a bit tuning of auth/authz settings in the administration Web ui).

by SQLite 10y ago

mysterydip 10y ago

Never heard of it before, but I'm grateful to hear about it! My projects were always small enough that a traditional version control system wasn't worth the time to set up. Just keep an archive of each day's progress in a folder and call it done. With my latest project, I'm maintaining multiple splits of the codebase for different platform-specific features, and sharing the code with a team member. I was about to bite the bullet and start installing cvs or git in a VM and going through the learning curve, but this seems right up my alley and the kind of system I'd mesh with well. Thanks!

lucaspiller 10y ago
> My projects were always small enough that a traditional version control system wasn't worth the time to set up There's no such thing as too small: I use Git for everything, including small scripts I may never use again. The setup is "mkdir fooscript && cd fooscript && git init". Plus using GitLuBucket means free backups.
- splitbrain 10y ago
  What is GitLuBucket? Google thinks you meant BitBucket, but it seems to be a very weird typo.
  - lucaspiller 10y ago
    GitHub/GitLab/BitBucket. Sorry it wasn't clear :-)
petre 10y ago
It's really easy to use and it has builtin help like mercurial. No need to read man pages. We use it for all our projects. I also use it for tracking config changes in /etc.
pablasso 10y ago
How is `git init` or `hg init` harder than maintaining different versions of your code in separate folders?
- Moru 10y ago
  It's usually the extra learning curve to use those commands in the first place, not that they are simple to use.

carterehsmith 10y ago

The fact that you created both an SCM, and a RDBMS, kind of forces the question: Does Fossil have something like 'rollback'? If not, would it not be good to have your standard SQL COMMIT/ROLLBACK semantics in an SCM? I mean, sometimes you do something with your SCM that you immediately regret. Like, you do a 'pull' expecting that perhaps a couple files will be changed, and instead you get a screenful of statuses, errors and whatnots. Ooops! So you look at what you typed, and turns out you were in a wrong branch, or you should have used 'pull x y' or whatever. In any case, what you want to do now, is to 'roll back' ('undo') the last command. Now, in SQL, when you make a mistake, you say 'rollback' and everything is good. But in a typical SCM, either you cannot do it at all, or it is nontrivial. E.g. in Git, the way to 'undo' depends on the command that you are undoing. Sometimes it is 'revert', sometimes 'reset ^XX~xx' or 'abort', etc etc, clearly not optimal. Is there an SCM that does that?

isxek 10y ago
Mercurial has a 'rollback' command, which they've marked as deprecated a few months (years?) ago, but you can still use it when you reach a tight spot.
- carterehsmith 10y ago
  Thanks, that's interesting. Hmm, reading about it, it looks like Mercurial's rollback "can be dangerous". That's kind of opposite of what you expect rollback to be.
  - e12e 10y ago
    In a vcs it seems natural that rollback is dangerous - it should be the only way to delete work? The only alternative would be to stash what is rolled back in a branch, or somewhere else on disk? At witch point it isn't really a rollback anymore? Aside from that, I think all major vcs will allow you to clone "up to revision N" which in turn will give you a new repository that has been rolled back to N?
    - 10y ago

i_feel_great 10y ago

"My intent is to continue personally supporting and maintaining Fossil for at least three more decades." Good to hear. This instill confidence in me for my continued use of both Fossil and the reason for its existence, SQLite. Thank you.

e12e 10y ago

I had hoped to use Fossil for a new class I'm teaching, but ended up using a combination of gogs (and git). The web UI is great, and the bundled wiki/bug tracking works fine - but I never could get anonymous push/user registration to work smoothly enough for my needs (we're on a LAN, currently with bring-your-own-device and no central ldap/ad etc). If it wasn't a group of 27 complete beginners (on Windows), I might have started people out with the basics of ssh and key generation - but in the end gogs had an easier start-up: single binary for me to deploy on a server, and git and vscode available for Windows via http://scoop.sh http://scoop.sh (as is Fossil :-)). In the end things worked out - we spent more time on work process, the usual fight with git for a sane workflow (mercurial, Fossil and gitless all make it a bit easier to clone/branch/merge/push than git does. I really don't want too think to much when I rebase, and I don't want to detach my head). The upside is that gogs is closer to the git/github workflow with git as the vcs tool and Web based "pull requests" -- which for better or worse has become standard. And it became an opportunity to show that project management really is about people, communication, cooperation and process - not the tools.

SQLite 10y ago
> I never could get anonymous push/user registration to work smoothly.... We are always trying to make Fossil better. Can you explain what you mean by "anonymous push/user registeration" and provide more information on why it was a problem for you? Private email to drh@sqlite.org is ok for this.
- e12e 10y ago
  The easiest way to explain this is probably through my scenario (and an example of how gogs worked, where Fossil fell a little short): I have 26 students, for whom I have no account information or central auth server (eg a typical "pop-up" workshop). As everyone is new to programming and (d)Vcs, I would prefer some authorization help from the system (Fossil is pretty good here, afaik "git push --force" isn't really an issue). Everyone are on Windows, and while ssh is available, it's not a great fit for the platform. Fossil has "fossil gui" and "fossil serve" which allow users to clone - but I never could get either: plain http (no ssl, as this isn't a public ip which complicates settling up a trusted cert a bit) with push from clients to work - with or without password. With gogs, I could turn off the CAPTCHA and enable registration in the Web ui, and users could push with auth from git and visual studio code, using user/passwords. As far as I got with Fossil was registering users that worked with the Web ui (eg: edit wiki) -- but I couldn't get sync (push to the server) to work (neither from Linux, nor Windows). At first I thought it was an issue with a mix of Fossil versions, but in the end I think that ad-hoc LAN deployments just isn't all that we'll tested? Perhaps especially on/with Windows clients? As far as I gather when cloning a repo, Fossil is supposed to get a copy of the user database, and so everyone should be able to a) use "fossil gui" and edit wiki pages etc and have changes auto-sync out of the box (assuming the upstream Fossil instance is up) and b) use "fossil serve" and have other registered users be able to push changes? I was able to pull, and sync/push over ssh, but (auto)sync over http always failed. From the docs, it looks like it is supposed work, with a bit tuning of auth/authz settings in the administration Web ui).