5 ms·

Related: Fossil SCM is a distributed source code manager (just like Git), but with the added benefit that documentation and issues also goes in the repository

Related: Fossil SCM is a distributed source code manager (just like Git), but with the added benefit that documentation and issues also goes in the repository (so like GitHub, but packed into the repository). When you clone a Fossil repository, you get everything, not just the code. http://fossil-scm.org/ http://fossil-scm.org/ Also been discussed on HN before, a selection: - Fossil VS Git (https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...) - https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 - https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=12673229 I haven't personally used it for more than toy projects, but looks very interesting and would love to use it more.

rkeene2 7y ago
Not just the Wiki and Issues, but also more things like release artifacts can be (optionally) sync'd and are part of the repository (as "unversioned content"). There's also a Forum included, and as with the rest those messages are distributed.
theamk 7y ago
Just don't forget that Fossil does not support rebase/amend, on principle. So if you want both "commit very often" and "have nice, readable commits with clear descriptions", it is not for you.
- thunderbong 7y ago
  You can't change history. In a version control system, this is axiom 0.
  - jdbernard 7y ago
    You can. That is certainly a possible axiom as evidenced by fossil and some others, but as evidenced by git and common usage it is not necessarily "axiom 0" for all possible VCS's. Unless you want to get really semantic in which case, sure "history" can't be changed, but "recorded history" certainly can.
  - theamk 7y ago
    Well, I need something where I store temporary files. Like right now, I am in the middle of prototyping major new functionality. It is huge, it is ugly (still) and it touches a half dozen of major subsystem. It is a huge blob of changes. When it will be ready, I'd have to split it to maybe 6 to 8 commits, with well written commit messages. But I cannot do this yet -- for all that I know, I'll find out my design was bad, and I'll have to change those things tomorrow. So the question is: what do I do with it? In the old days, I had a VCS which could not change history (SVN). So I'd keep multiple worktrees and back them up manually ("project-2009-12-03.tar.gz", "file1.cc.before-refactor") and so on. The data would be lost sometimes. It was a pain generally. Now, I have a git branch. It has commit messages like "fix crash in Foo()", "what if we used trie?", "oops forgot to update Bar to match" and so on. They should never see the light of day, and they won't -- they'll get re-made into different commits later. And git will help me to make sure the changes are not lost. It looks like with the fossil, I should be going back to multiple worktrees and manual backups. I don't understand why would one want to do so.
    - rkeene2 7y ago
      With Fossil you could create many private branches off your feature branch with your experiments, and merge them into your feature branch when you're satisfied with that experiment.
      - theamk 7y ago
        that's the thing -- I'll be making 6-8 different branches out of that experimental branch. In rebase world, I have a cycle of "cherry-pick a few changes, get them into master, rebase experimental so it gets smaller; repeat until nothing is left of experimental" In permanent world, I guess I have two worktrees and copy files one-by-one, manually?
        hinkley 7y ago
        Seems like you should be able to write a 'rebase' tool that just does a sequential cherry-pick...
  - deleted 7y ago
    [deleted]
  - renewiltord 7y ago
    That's a way for you to live your life by and Fossil will work for you. I don't use that axiom, rampantly alter history all the time, and Fossil is not for me. I'm glad that person mentioned it.
- capableweb 7y ago
  Yup, that's true, by design it's like that. You (not you specifically theamk, but others who might be interested in the _why_ of rebasing/amending is not in Fossil) can read more about it here: https://www.fossil-scm.org/xfer/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/xfer/doc/trunk/www/rebaseharm.md
  - theamk 7y ago
    I read this document every once in a while, and I envy Fossil's author. He clearly is a much better programmer than I am. For example, he says things like: > Git lets a developer write a feature in ten check-ins but collapse it down to an eleventh check-in and then deliberately push only that final collapsed check-in to the parent repo > Fossil pushes all 11 check-ins to the parent repository by default, so that someone doing that bisect sees the complete check-in history, so the bisect will point them at the single original check-in that caused the problem. And I think: Well, it'll work if you are drh.. I know if I were in this situation, commit 3 is broken because I forgot to run tests, commit 5 would not even compile because I made it just before going home, and the main app would not even work until commit 8 because I focused on the unit tests.. My non-final commits are messy. I don't want to inflict them on people.
    - saltcured 7y ago
      I've been working primarily in public, shared repositories for almost 25 years with open source projects that have used cvs, svn, and git. A big step is to let go of the fear that you might be embarrassed by what you commit. That is partly about managing your own anxieties and partly about developing a culture that supports people and recognizes nobody is perfect. Still, there is a real part where you learn from mistakes and get better at making low-embarrassment commits over time. A team has to expect this when onboarding newer participants and mentor and support appropriately. A second, equally important step is to adopt tools and methods which allow the appropriate amount of build and test for your team. If you insist on full continuous-integration and an always-working master branch, you had better make sure people can run build-and-test cycles from a working copy, prior to any commit. On the other hand, if you have focused on automated build-and-test being driven by commits, you had better adopt an appropriate branch and merge strategy to tolerate the fact that untested things are going to be committed as a regular event! With git, I think the disconnect people have is that you should not be rebasing or amending history that you have already shared. Someone following along in a shared repo should never have the rug pulled out from them, putting their own tools into a broken state. I would much rather see an uglier commit history than feel like I am being gaslit by transient errors and here-today, gone-tomorrow commits. Depending on your exact tools, sharing might mean pushes to the central repo or everything in your own self-hosted repo that you allow others to see, even read-only. If using a sharing model like github, that means you could feel free to rebase or amend only the batch of changes since your last push to upstream. Nobody looks at your own local clone of the repo. Every push should monotonically move the history forward in a way that all observers will see the same way. I wouldn't care if you amended commits before you pushed them, since I could never see the earlier drafts. I also would not care if there are some buggy commits in your personal working branch, as long as you address them with further commits before attempting a pull request or other merge to a shared integration branch. But, I should never be able to pull twice in any available branch and face a bizarre merge-conflict because you amended something in between my pulls. Also, many teams can benefit from earlier sharing to avoid different private efforts from diverging too far and creating larger integration headaches or dead ends. Seeing individual commits that expose developer thought process can also help with communicating new ideas or identifying potential problems. Large rebases can interfere with this. Some organizations also will find it easier to do disaster mitigation if they know that all work products are pushed regularly (e.g. daily) to a shared repository, rather than having to worry about many distributed repos holding sole copies of new work. Such shared, periodic snapshots put an upper bound on how much work product you might be able to amend/rebase without sharing.
- u801e 7y ago
  > So if you want both "commit very often" I honestly think that commit very often is overrated. It really ought to be save and back up your files very often. When I implement something, I don't bother making commits until I have completed the features. I then take the diff against the code and then selectively stage parts of the diff and make commits out of them. If someone else wants to see what was done so far, I just send them the diff as it is.
  - icholy 7y ago
    > It really ought to be save and back up your files very often. Git is the backup.
    - u801e 7y ago
      git is really meant to show a meaningful log of changes to the codebase. If one wanted to use it as a backup, there's no reason why one couldn't configure their editor to just run git commit -a -m "<current timestamp>" every time they saved, but that wouldn't result in a history that's useful in terms of being able to tell what actually changed and why.
      - theamk 7y ago
        I worked in online IDEs which did automatic backups, and it was useless. Those timestamps don’t mean anything to me, and diff interface was very bad. But semi-automatic backups, a.k.a. frequent git commits, are very helpful. For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea. Of course no one else, including me, would care about this once the feature is done, and that’s where rebase comes in.
        u801e 7y ago
        > For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea. If you're going to end up squashing all those in progress commits down to a single commit, then that will work. If you're going to try to make several logical commits, then it becomes a bit more difficult (unless you just take the diff from the original branch and start over on a new branch). I actually find that using the multi-level undo feature in my editor sufficient for trying out small changes to see if they work or not. That is, if I get to a point where I can't figure out what I messed up, I can simply run something like :earlier 5m to go back to what the state was 5 minutes ago and get back to a working state.
- Groxx 7y ago
  Though I personally rebase and rewrite history fairly frequently, so each step is friendlier to reviewers and works independently: Couldn't you make a new history branch, copy/paste as needed from the original one, and just abandon the old history? That's effectively what git does under the hood anyway - all your shas are changed, but the old ones are left around. If you haven't named (branch/tag) them, you just don't see them normally, and they may eventually get garbage collected.
bachmeier 7y ago
Something very nice is that the issue tracker is nothing but an SQLite database. You can customize it any way you like, running arbitrary SQL queries on it, and generating any html you want. I use it for notes, among other things. In addition, you can extend it in any language using a CGI program.

rkeene2 7y ago

Not just the Wiki and Issues, but also more things like release artifacts can be (optionally) sync'd and are part of the repository (as "unversioned content"). There's also a Forum included, and as with the rest those messages are distributed.

theamk 7y ago

Just don't forget that Fossil does not support rebase/amend, on principle. So if you want both "commit very often" and "have nice, readable commits with clear descriptions", it is not for you.

thunderbong 7y ago
You can't change history. In a version control system, this is axiom 0.
- jdbernard 7y ago
  You can. That is certainly a possible axiom as evidenced by fossil and some others, but as evidenced by git and common usage it is not necessarily "axiom 0" for all possible VCS's. Unless you want to get really semantic in which case, sure "history" can't be changed, but "recorded history" certainly can.
- theamk 7y ago
  Well, I need something where I store temporary files. Like right now, I am in the middle of prototyping major new functionality. It is huge, it is ugly (still) and it touches a half dozen of major subsystem. It is a huge blob of changes. When it will be ready, I'd have to split it to maybe 6 to 8 commits, with well written commit messages. But I cannot do this yet -- for all that I know, I'll find out my design was bad, and I'll have to change those things tomorrow. So the question is: what do I do with it? In the old days, I had a VCS which could not change history (SVN). So I'd keep multiple worktrees and back them up manually ("project-2009-12-03.tar.gz", "file1.cc.before-refactor") and so on. The data would be lost sometimes. It was a pain generally. Now, I have a git branch. It has commit messages like "fix crash in Foo()", "what if we used trie?", "oops forgot to update Bar to match" and so on. They should never see the light of day, and they won't -- they'll get re-made into different commits later. And git will help me to make sure the changes are not lost. It looks like with the fossil, I should be going back to multiple worktrees and manual backups. I don't understand why would one want to do so.
  - rkeene2 7y ago
    With Fossil you could create many private branches off your feature branch with your experiments, and merge them into your feature branch when you're satisfied with that experiment.
    - theamk 7y ago
      that's the thing -- I'll be making 6-8 different branches out of that experimental branch. In rebase world, I have a cycle of "cherry-pick a few changes, get them into master, rebase experimental so it gets smaller; repeat until nothing is left of experimental" In permanent world, I guess I have two worktrees and copy files one-by-one, manually?
      - hinkley 7y ago
        Seems like you should be able to write a 'rebase' tool that just does a sequential cherry-pick...
- deleted 7y ago
  [deleted]
- renewiltord 7y ago
  That's a way for you to live your life by and Fossil will work for you. I don't use that axiom, rampantly alter history all the time, and Fossil is not for me. I'm glad that person mentioned it.
capableweb 7y ago
Yup, that's true, by design it's like that. You (not you specifically theamk, but others who might be interested in the _why_ of rebasing/amending is not in Fossil) can read more about it here: https://www.fossil-scm.org/xfer/doc/trunk/www/rebaseharm.md https://www.fossil-scm.org/xfer/doc/trunk/www/rebaseharm.md
- theamk 7y ago
  I read this document every once in a while, and I envy Fossil's author. He clearly is a much better programmer than I am. For example, he says things like: > Git lets a developer write a feature in ten check-ins but collapse it down to an eleventh check-in and then deliberately push only that final collapsed check-in to the parent repo > Fossil pushes all 11 check-ins to the parent repository by default, so that someone doing that bisect sees the complete check-in history, so the bisect will point them at the single original check-in that caused the problem. And I think: Well, it'll work if you are drh.. I know if I were in this situation, commit 3 is broken because I forgot to run tests, commit 5 would not even compile because I made it just before going home, and the main app would not even work until commit 8 because I focused on the unit tests.. My non-final commits are messy. I don't want to inflict them on people.
  - saltcured 7y ago
    I've been working primarily in public, shared repositories for almost 25 years with open source projects that have used cvs, svn, and git. A big step is to let go of the fear that you might be embarrassed by what you commit. That is partly about managing your own anxieties and partly about developing a culture that supports people and recognizes nobody is perfect. Still, there is a real part where you learn from mistakes and get better at making low-embarrassment commits over time. A team has to expect this when onboarding newer participants and mentor and support appropriately. A second, equally important step is to adopt tools and methods which allow the appropriate amount of build and test for your team. If you insist on full continuous-integration and an always-working master branch, you had better make sure people can run build-and-test cycles from a working copy, prior to any commit. On the other hand, if you have focused on automated build-and-test being driven by commits, you had better adopt an appropriate branch and merge strategy to tolerate the fact that untested things are going to be committed as a regular event! With git, I think the disconnect people have is that you should not be rebasing or amending history that you have already shared. Someone following along in a shared repo should never have the rug pulled out from them, putting their own tools into a broken state. I would much rather see an uglier commit history than feel like I am being gaslit by transient errors and here-today, gone-tomorrow commits. Depending on your exact tools, sharing might mean pushes to the central repo or everything in your own self-hosted repo that you allow others to see, even read-only. If using a sharing model like github, that means you could feel free to rebase or amend only the batch of changes since your last push to upstream. Nobody looks at your own local clone of the repo. Every push should monotonically move the history forward in a way that all observers will see the same way. I wouldn't care if you amended commits before you pushed them, since I could never see the earlier drafts. I also would not care if there are some buggy commits in your personal working branch, as long as you address them with further commits before attempting a pull request or other merge to a shared integration branch. But, I should never be able to pull twice in any available branch and face a bizarre merge-conflict because you amended something in between my pulls. Also, many teams can benefit from earlier sharing to avoid different private efforts from diverging too far and creating larger integration headaches or dead ends. Seeing individual commits that expose developer thought process can also help with communicating new ideas or identifying potential problems. Large rebases can interfere with this. Some organizations also will find it easier to do disaster mitigation if they know that all work products are pushed regularly (e.g. daily) to a shared repository, rather than having to worry about many distributed repos holding sole copies of new work. Such shared, periodic snapshots put an upper bound on how much work product you might be able to amend/rebase without sharing.
u801e 7y ago
> So if you want both "commit very often" I honestly think that commit very often is overrated. It really ought to be save and back up your files very often. When I implement something, I don't bother making commits until I have completed the features. I then take the diff against the code and then selectively stage parts of the diff and make commits out of them. If someone else wants to see what was done so far, I just send them the diff as it is.
- icholy 7y ago
  > It really ought to be save and back up your files very often. Git is the backup.
  - u801e 7y ago
    git is really meant to show a meaningful log of changes to the codebase. If one wanted to use it as a backup, there's no reason why one couldn't configure their editor to just run git commit -a -m "<current timestamp>" every time they saved, but that wouldn't result in a history that's useful in terms of being able to tell what actually changed and why.
    - theamk 7y ago
      I worked in online IDEs which did automatic backups, and it was useless. Those timestamps don’t mean anything to me, and diff interface was very bad. But semi-automatic backups, a.k.a. frequent git commits, are very helpful. For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea. Of course no one else, including me, would care about this once the feature is done, and that’s where rebase comes in.
      - u801e 7y ago
        > For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea. If you're going to end up squashing all those in progress commits down to a single commit, then that will work. If you're going to try to make several logical commits, then it becomes a bit more difficult (unless you just take the diff from the original branch and start over on a new branch). I actually find that using the multi-level undo feature in my editor sufficient for trying out small changes to see if they work or not. That is, if I get to a point where I can't figure out what I messed up, I can simply run something like :earlier 5m to go back to what the state was 5 minutes ago and get back to a working state.
Groxx 7y ago
Though I personally rebase and rewrite history fairly frequently, so each step is friendlier to reviewers and works independently: Couldn't you make a new history branch, copy/paste as needed from the original one, and just abandon the old history? That's effectively what git does under the hood anyway - all your shas are changed, but the old ones are left around. If you haven't named (branch/tag) them, you just don't see them normally, and they may eventually get garbage collected.

bachmeier 7y ago

Something very nice is that the issue tracker is nothing but an SQLite database. You can customize it any way you like, running arbitrary SQL queries on it, and generating any html you want. I use it for notes, among other things. In addition, you can extend it in any language using a CGI program.