8 ms·

Fossil SCM keeps more than just your code

73 points by kotnik 11y ago

thecatspaw 11y ago
In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightweight ticketing system etc., than one system which does it all.
- jimktrains2 11y ago
  > Having Tickets, the Wiki and technotes in the same place is an interesting idea, Couldn't you just have a `bugs`, and `notes` branch? gugs would be a folder per bug, with each message being a MIME or some similar message format. notes would be a collection of md, rst, textile, &c similar to how github already has a gh-pages branch. It wouldn't need to be part of the scm, but simply be convention.
  - feld 11y ago
    This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.
    - w_t_payne 11y ago
      The user interface is a separate concern from the serialisation format.
    - jimktrains2 11y ago
      1) I never even mentioned a UI or how the user would interact with what I proposed. 2) Even if you just edited files with a text editor, how is that not user friendly? It's about as friendly as it could possibly be.
  - WorldMaker 11y ago
    The benefit to having it in the same branch/associated with a specific branch of code is that it makes it easier to have those issues and notes represent the current state of that branch and as you merge branches for that information to similar flow across the merges just as with the associated code. For example, say you fix a bug in a specific branch. If the issue is being tracked inside that branch you can mark it as fixed in that branch, and then checking if an issue is fixed in a given branch is a matter of checking the issue state for that branch. As you merge that code change to other branches, the flag that the issue has been fixed presumably flows with the merge as well and you have an easier time of telling the particular state of any given branch.
- jordigh 11y ago
  > In my books its a minus that you can not rewrite history. Yeah. Here Mercurial has a very good idea. It records which commits are public and immutable and which commits are drafts and editable. A draft becomes immutable once published, but public commits can always go back to being drafts with a --force, incurring an "everyone out of the pool" scenario. There's nothing wrong with rewriting commits as long as everyone agrees where the boundary lies between published history and drafts. For git, this boundary is often set by a convention such as this: rewrite feature branches all you want, but master must never be rewritten.
- ibmthrowaway271 11y ago
  > In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.
  - thecatspaw 11y ago
    Yes, but then you are fighting the software, and it wouldnt need to be immutable at all if you can change it anyway
  - sgbeal 11y ago
    > Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history. No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.
    - pdw 11y ago
      Git is the same, if you rebase many hashes will be recalculated, and the "tampering" would be obvious to anyone who had a copy of the repository. It is possible to implement the equivalent of rebase in any distributed VCS, the authors of Fossil simply chose not to. If it becomes more popular, somebody else likely will.
      - sgbeal 11y ago
        i've been on the fossil dev team since 2008, and i have seen many people claim that it "could" be compromised/modified post facto, and yet... nobody has been able to do it. Fossil's core data model does not just _assume_ that history doesn't change - it makes it essentially impossible to do. Shunning is a special case which removes a given artifact from the db, but is considered a "nuclear option" of last resort. i've never personally used it.
    - 11y ago
- panic 11y ago
  What happens if you accidentially add code where you dont own the copyright? Or an API Secret? http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki
  - masklinn 11y ago
    So… not that different from git after all? (rebasing creates new revisions, but while the old ones may not be trivially accessible anymore they're still there until garbage collected)
    - krupan 11y ago
      Right. You can also "purge" private branches: http://fossil-scm.org/xfer/doc/trunk/www/private.wiki http://fossil-scm.org/xfer/doc/trunk/www/private.wiki It's interesting how both Fossil and Mercurial (and others?) first took strong stances against "changing history" and then softened those stances over time.
    - wyoung2 11y ago
      Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose. Fossil's shun operation and private branches are entirely different from rebasing. First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and if you do the shun on a central repo, any clones of it that were made before the shun don't copy the shun record, so they keep their local copies of the shunned artifact. The only way to propagate a shunning operation through a clone network is cooperatively: you have to ask everyone to agree to shun that artifact in their local clones, then rebuild their repositories. As for private branches being a "history rewriting" mechanism, that's nonsense. Changes made to a private branch are never part of the history on the repo you cloned from in the first place. They're analogous to the default working mode of Git, where your checkins aren't immediately sync'd to the repo you cloned from. If you never sync, or you purge your local changes, history doesn't get rewritten, the changes just never become part of the official history in the first place.
- krupan 11y ago
  Rewriting history was considered Very Bad by most everyone who had not yet used distributed version control much. The set of people that had not yet used distributed version control much included everyone, even the developers of distributed version control tools. After we all started using DVCSes more we realized how useful and powerful it was to be able to rewrite local history. Fossil developers are apparently still catching up to this idea but as pointed out in other replies here it does have some history rewriting features. Even its recommendation that you pull and merge others' changes with yours before you commit your changes (in the style of CVS or SVN, they call it "autosync") is a form of rewriting history. See: http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki
  - w_t_payne 11y ago
    Yeah ... the key here is the qualifier "local".
- kabdib 11y ago
  You can always rewrite history, just do a replay into a snapshot of the repository (modifying the system time, or noodling the app to inject the timestamps you want). I guess you could arrange for some trusted external time authority to sign hashes of commits. That'd be interesting.
- rbehrends 11y ago
  > In my books its a minus that you can not rewrite history. To quote Richard Hipp, the primary author of Fossil and SQLite [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." About DO-178B: https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B In short: Fossil is designed for a different purpose than Git. Note that even then, in Fossil – as with every system that represents data in purely electronic format – nothing is truly immutable. And Fossil does have ways to excise data from history (shunning, "fossil purge", etc.). You can even run raw SQL queries on the underlying SQLite database if you want or use "fossil deconstruct/reconstruct" to break down a repository into its constituent artifacts and rebuild it. However, these are generally methods of last resort and there are no frontend facilities to easily integrate them into your workflow (other than, arguably, "fossil purge", which is local only). [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
jordigh 11y ago
This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal. Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy. With offerings like gitlab, it might not make a huge difference, but contenders like Fossil or hg have some good non-git ideas worth exploring.
- jimktrains2 11y ago
  > Almost nobody uses just git -- they use github or gitlab. I don't understand what you mean. I know plenty of people that simply use SSH or local-only repositories. If you intend on sharing said repo, github is essentially cheap shared hosting (or did you also complain that people didn't run their own httpd?).
  - jordigh 11y ago
    I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?
    - crististm 11y ago
      We don't know how many people are using SSH git but you surely know they are much less than 3 million. Have you heard about Dunning-Kruger effect?
      - jordigh 11y ago
        Yes, I assume you are indicating that I think my skill is greater than it actually is? Which skill are you referring to? Or whose skill are you referring to?
wereHamster 11y ago
> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the internal data model to be quite complicated, but certainly not impossible. I don't understand the hate against rebase. Nobody uses it with malicious intent. And, those who do, will have no problem working around fossil's immutability.
- jimktrains2 11y ago
  > Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm working locally, commit an absurd number of commits in stream-of-programming style, and then go back and clean it up before pushing to the shared repo. What is the analogous workflow in fossil?
  - sgbeal 11y ago
    > What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
    - avar 11y ago
      That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you. What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew. Nobody needs audibility on unfinished work that hasn't been pushed to the central repositories (and would thus be protected by non-fast-forward). To the extent that you would fossil doesn't make the situation better, if I can't fix up my commits after the fact before I push them I'm just not going to make those intermediate commits in the first place, which gives the system no more information to work with, and results in a less convenient workflow for me. This whole "we preserve history forever" statement is a red herring. They've just picked a data model which is hard-immutable, but it doesn't mean that they're categorically preserving more information, or that tools that have configurable-immutable datamodels (like Git) preserve less history in practice.
mkj 11y ago
Being from Richard Hipp, the author of SQLite, it should be a pretty high quality program.
w_t_payne 11y ago
I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or something richer. To tie everything together, I maintain a diary, which consists of one text file per developer per sprint. This diary holds allocated jobs to do each sprint, together with a record of what was done each day. Because all of my work information is available in the repository as text (markdown or YAML or JSON) - it means that I can automate my workflow in ways that would be much harder to achieve otherwise. For example, I can extract appropriate git commit messages automatically from this diary, meaning that I have perfect traceability back to requirements on every commit. I can get my build to (optionally) commit changes automatically (rolling back if the build was not successful). I can even get it to (again optionally) make sure that all changes associated with a particular job are kept on a separate branch until that job is complete. In other words, I have lots of options when it comes to tying my workflow together with my CMS/VCS in an automated and scripted way. And all because I am too lazy to open my web browser to look at JIRA or Trac (or whatever). :-)
- w_t_payne 11y ago
  It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.
  - madeofpalk 11y ago
    > sort of like a TODO but with super-powers. Funnily enough our team just introduced an eslint warning (https://github.com/eslint/eslint/blob/master/docs/rules/no-warning-comments.md https://github.com/eslint/eslint/blob/master/docs/rules/no-w...) to discourage those TODO comments as we found they just always sat around forever collecting lint.
noinsight 11y ago
Fossil is a great, simple system. It's especially good with Windows because (imo) it integrates much better than the others since it's just a single binary you can put in your $PATH. Git especially seems so hacky.
speps 11y ago
By the way, does anyone know of a SCM written in Go? It seems that the feature list of Fossil would fit Go pretty well, the networking/local web UI stuff for example, self-contained binary as well.
- JustSomeNobody 11y ago
  They should all be written in ANSI C. C90, specifically.
  - falcolas 11y ago
    I appreciate the motivation behind this ideology, but giving up 26 years of advancement in programming languages (not to mention security and safety) for compatibility with a vanishingly small number of operating systems (few, if any, of which are in use as development machines) is not worth it for tools like these.
CodexArcanum 11y ago
I was introduced to Fossil through a previous HN post and I love it. For smaller personal projects, it's the best. I like that I can just put the repo file into Dropbox and then have my project's tickets, documentation, and code all in one place. And from someone who doesn't write much C, I will say that the source is very easy to read and poke around in. Just a great project all around.
sspiff 11y ago
I use Fossil for personal, private projects. I've never used it with other people. But being able to replicate the wiki, issues etc and version them is very cool. I use fossil to keep track of my code and use the wiki of a project as a scratchpad, design document, and general notes. I love it. It can be self-hosted using a super-simple CGI script: #!/usr/bin/fossil repository: /path/to/project/repository.fossil - which allows you to both clone over HTTP/HTTPS and access the Wiki and issue tracker via your browser. It has pretty decent access control and can allow you to configure a set of wiki pages to make read-only accessible to everyone, even when not logged in, to use as a project landing page for visitors. You can also customize the CSS of a project, which is also versioned in the single sqlite db backing a repository.
diego_moita 11y ago
Fossil is neat and the idea of a tickets tracker and wiki within the repo is very productive. However I got spoiled by the power of Git. So what I do now is to keep a TiddlyWiki[1] on the Git repo, so I have the best of both worlds. [1] http://tiddlywiki.com/ http://tiddlywiki.com/
- wyoung2 11y ago
  While I am a fan of chains of small cooperating tools, there is something to be said for a single large tool with a well-integrated feature set. Here are some of the advantages you get when the code repo, bug tracker, and wiki are all part of the same coherent system: 1. When a checkin fixes a bug noted in the ticket tracker, you can reference it in the checkin comment with a subset of the ticket ID: "Fixes [3b52b91fc]" That ticket ID becomes clickable in the web view of the timeline, taking you directly to the referenced ticket. Yes, I know, this is not a unique feature, but the other systems that have this also integrate the ticket tracker and code repo. The point is that you get this feature out of the box with Fossil, for free. 2. Your next step is to close the bug ticket. This modifies the appearance of the checkin comment you created in the previous step in the Fossil UI timeline view, rendering the ticket ID as strikethrough text, so you can see it refers to a closed ticket without clicking on it. The key point here is that the integration is bidirectional. (It would be even neater if Fossil would recognize the pattern "Fixes [artifact-ID]" in checkin comments and automatically close the ticket for you. It shouldn't be too difficult to add, since it's a unified system.) 3. Anywhere that Fossil accepts regular URLs, it will also accept artifact IDs. So, you can refer to checkins or tickets from the wiki, or from within a Markdown document checked into the code repo. 4. Because Fossil understands Markdown as one of its available wiki article formats, it can render Markdown documents in the code repo inside the Fossil UI when you click on them from the Files tab in the web UI. 5. That feature extends to other document types, too. This leads to the embedded documentation feature (http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki) which is a versioned alternative to the wiki. You use the wiki for articles that apply to all versions of the repository, or at least to the current trunk version. Where you instead need a given doc article to roll back to its historical content when you roll back the code, you want to use embedded documentation instead. You can use the wiki and embedded docs interchangeably, linking from one to the other, as needed.
node_uzer 11y ago
I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I've customized the "fossil ui" to my liking. However, fossil does lacks some important features that svn, hg and git have: * Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. * Cannot perform a "fossil diff" for just a directory and its descendants - i.e., no fossil equivalent of the following: # produce a diff for this directory and its descendants git diff . * A "fossil merge" between distributed repos it will give commit attribution to the wrong user for all files in the merge - changes will be recorded as being made by the user performing the merge. This is particularly annoying because it makes "fossil blame" on a given file less effective when pinpointing who introduced what change. There are other fossil issues, but those are the biggest ones that come to mind.
- jordigh 11y ago
  > Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. Hm? Neither git nor hg allow this either. The usual workaround in both is to put an placeholder file in the desired "empty" directory, such as a .gitignore.
  - node_uzer 11y ago
    hg and svn support versioning directories. I assumed that git also did. If it does not, I stand corrected.
  - node_uzer 11y ago
    You're also correct about hg not versioning empty directories with the default mercurial install. A previous place I worked had a non-standard extension - that unknown to me may very well have used the .keep file trick you described. So it would appear that fossil not supporting versioning of directories puts it in good SCM company.
- 11y ago

73 points by kotnik 11y ago

In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightweight ticketing system etc., than one system which does it all.

jimktrains2 11y ago
> Having Tickets, the Wiki and technotes in the same place is an interesting idea, Couldn't you just have a `bugs`, and `notes` branch? gugs would be a folder per bug, with each message being a MIME or some similar message format. notes would be a collection of md, rst, textile, &c similar to how github already has a gh-pages branch. It wouldn't need to be part of the scm, but simply be convention.
- feld 11y ago
  This sounds horrible. Why would you think this is something people should be subjected to? The polar opposite of user friendly.
  - w_t_payne 11y ago
    The user interface is a separate concern from the serialisation format.
  - jimktrains2 11y ago
    1) I never even mentioned a UI or how the user would interact with what I proposed. 2) Even if you just edited files with a text editor, how is that not user friendly? It's about as friendly as it could possibly be.
- WorldMaker 11y ago
  The benefit to having it in the same branch/associated with a specific branch of code is that it makes it easier to have those issues and notes represent the current state of that branch and as you merge branches for that information to similar flow across the merges just as with the associated code. For example, say you fix a bug in a specific branch. If the issue is being tracked inside that branch you can mark it as fixed in that branch, and then checking if an issue is fixed in a given branch is a matter of checking the issue state for that branch. As you merge that code change to other branches, the flag that the issue has been fixed presumably flows with the merge as well and you have an easier time of telling the particular state of any given branch.
jordigh 11y ago
> In my books its a minus that you can not rewrite history. Yeah. Here Mercurial has a very good idea. It records which commits are public and immutable and which commits are drafts and editable. A draft becomes immutable once published, but public commits can always go back to being drafts with a --force, incurring an "everyone out of the pool" scenario. There's nothing wrong with rewriting commits as long as everyone agrees where the boundary lies between published history and drafts. For git, this boundary is often set by a convention such as this: rewrite feature branches all you want, but master must never be rewritten.
ibmthrowaway271 11y ago
> In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret? Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.
- thecatspaw 11y ago
  Yes, but then you are fighting the software, and it wouldnt need to be immutable at all if you can change it anyway
- sgbeal 11y ago
  > Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history. No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.
  - pdw 11y ago
    Git is the same, if you rebase many hashes will be recalculated, and the "tampering" would be obvious to anyone who had a copy of the repository. It is possible to implement the equivalent of rebase in any distributed VCS, the authors of Fossil simply chose not to. If it becomes more popular, somebody else likely will.
    - sgbeal 11y ago
      i've been on the fossil dev team since 2008, and i have seen many people claim that it "could" be compromised/modified post facto, and yet... nobody has been able to do it. Fossil's core data model does not just _assume_ that history doesn't change - it makes it essentially impossible to do. Shunning is a special case which removes a given artifact from the db, but is considered a "nuclear option" of last resort. i've never personally used it.
  - 11y ago
panic 11y ago
What happens if you accidentially add code where you dont own the copyright? Or an API Secret? http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki
- masklinn 11y ago
  So… not that different from git after all? (rebasing creates new revisions, but while the old ones may not be trivially accessible anymore they're still there until garbage collected)
  - krupan 11y ago
    Right. You can also "purge" private branches: http://fossil-scm.org/xfer/doc/trunk/www/private.wiki http://fossil-scm.org/xfer/doc/trunk/www/private.wiki It's interesting how both Fossil and Mercurial (and others?) first took strong stances against "changing history" and then softened those stances over time.
  - wyoung2 11y ago
    Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose. Fossil's shun operation and private branches are entirely different from rebasing. First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and if you do the shun on a central repo, any clones of it that were made before the shun don't copy the shun record, so they keep their local copies of the shunned artifact. The only way to propagate a shunning operation through a clone network is cooperatively: you have to ask everyone to agree to shun that artifact in their local clones, then rebuild their repositories. As for private branches being a "history rewriting" mechanism, that's nonsense. Changes made to a private branch are never part of the history on the repo you cloned from in the first place. They're analogous to the default working mode of Git, where your checkins aren't immediately sync'd to the repo you cloned from. If you never sync, or you purge your local changes, history doesn't get rewritten, the changes just never become part of the official history in the first place.
krupan 11y ago
Rewriting history was considered Very Bad by most everyone who had not yet used distributed version control much. The set of people that had not yet used distributed version control much included everyone, even the developers of distributed version control tools. After we all started using DVCSes more we realized how useful and powerful it was to be able to rewrite local history. Fossil developers are apparently still catching up to this idea but as pointed out in other replies here it does have some history rewriting features. Even its recommendation that you pull and merge others' changes with yours before you commit your changes (in the style of CVS or SVN, they call it "autosync") is a form of rewriting history. See: http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki http://fossil-scm.org/xfer/doc/trunk/www/concepts.wiki
- w_t_payne 11y ago
  Yeah ... the key here is the qualifier "local".
kabdib 11y ago
You can always rewrite history, just do a replay into a snapshot of the repository (modifying the system time, or noodling the app to inject the timestamps you want). I guess you could arrange for some trusted external time authority to sign hashes of commits. That'd be interesting.
rbehrends 11y ago
> In my books its a minus that you can not rewrite history. To quote Richard Hipp, the primary author of Fossil and SQLite [1]: "Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs." About DO-178B: https://en.wikipedia.org/wiki/DO-178B https://en.wikipedia.org/wiki/DO-178B In short: Fossil is designed for a different purpose than Git. Note that even then, in Fossil – as with every system that represents data in purely electronic format – nothing is truly immutable. And Fossil does have ways to excise data from history (shunning, "fossil purge", etc.). You can even run raw SQL queries on the underlying SQLite database if you want or use "fossil deconstruct/reconstruct" to break down a repository into its constituent artifacts and rebuild it. However, these are generally methods of last resort and there are no frontend facilities to easily integrate them into your workflow (other than, arguably, "fossil purge", which is local only). [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...

jordigh 11y ago

This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal. Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy. With offerings like gitlab, it might not make a huge difference, but contenders like Fossil or hg have some good non-git ideas worth exploring.

jimktrains2 11y ago
> Almost nobody uses just git -- they use github or gitlab. I don't understand what you mean. I know plenty of people that simply use SSH or local-only repositories. If you intend on sharing said repo, github is essentially cheap shared hosting (or did you also complain that people didn't run their own httpd?).
- jordigh 11y ago
  I know plenty of people that simply use SSH or local-only repositories. These people are the minority. Do you know at least 3 million people who use git without github? If not, you're nowhere near to saying that a majority of git users do not use github. And yes, having somewhere to host it is very important. Both Fossil and hg have an httpd built-in. I believe cgit or gitweb are not a simple "git serve" away?
  - crististm 11y ago
    We don't know how many people are using SSH git but you surely know they are much less than 3 million. Have you heard about Dunning-Kruger effect?
    - jordigh 11y ago
      Yes, I assume you are indicating that I think my skill is greater than it actually is? Which skill are you referring to? Or whose skill are you referring to?

wereHamster 11y ago

> Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it. Ehm, That's not a fair assessment. Git is as much immutable as fossil. In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the internal data model to be quite complicated, but certainly not impossible. I don't understand the hate against rebase. Nobody uses it with malicious intent. And, those who do, will have no problem working around fossil's immutability.

jimktrains2 11y ago
> Ehm, That's not a fair assessment. Git is as much immutable as fossil. I'm not familiar with fossil, but in git if update my HEAD and the REMOTE head isn't a simple fast-forward I get an error. So while the repo's history isn't immutable, each individual commit (and its history) _is_ immutable (modulo sha1 hash collisions). What is the value in having history be static? I find that rebase comes in handy as I'm working locally, commit an absurd number of commits in stream-of-programming style, and then go back and clean it up before pushing to the shared repo. What is the analogous workflow in fossil?
- sgbeal 11y ago
  > What is the value in having history be static? auditability, for one. Certain business processes, e.g. those sending people and machines into space, require 100% immutable auditability.
  - avar 11y ago
    That's something you can easily attain in Git as well, your central repository just denies non-fast-forwards, which gives you exactly what fossil is giving you. What fossil is denying you is the ability to rewrite all history for whatever reason, whether that's because you want to squash multiple commits or have decided (after audits etc.) that you really want to rewrite your central history and start anew. Nobody needs audibility on unfinished work that hasn't been pushed to the central repositories (and would thus be protected by non-fast-forward). To the extent that you would fossil doesn't make the situation better, if I can't fix up my commits after the fact before I push them I'm just not going to make those intermediate commits in the first place, which gives the system no more information to work with, and results in a less convenient workflow for me. This whole "we preserve history forever" statement is a red herring. They've just picked a data model which is hard-immutable, but it doesn't mean that they're categorically preserving more information, or that tools that have configurable-immutable datamodels (like Git) preserve less history in practice.

mkj 11y ago

Being from Richard Hipp, the author of SQLite, it should be a pretty high quality program.

w_t_payne 11y ago

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or something richer. To tie everything together, I maintain a diary, which consists of one text file per developer per sprint. This diary holds allocated jobs to do each sprint, together with a record of what was done each day. Because all of my work information is available in the repository as text (markdown or YAML or JSON) - it means that I can automate my workflow in ways that would be much harder to achieve otherwise. For example, I can extract appropriate git commit messages automatically from this diary, meaning that I have perfect traceability back to requirements on every commit. I can get my build to (optionally) commit changes automatically (rolling back if the build was not successful). I can even get it to (again optionally) make sure that all changes associated with a particular job are kept on a separate branch until that job is complete. In other words, I have lots of options when it comes to tying my workflow together with my CMS/VCS in an automated and scripted way. And all because I am too lazy to open my web browser to look at JIRA or Trac (or whatever). :-)

w_t_payne 11y ago
It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.
- madeofpalk 11y ago
  > sort of like a TODO but with super-powers. Funnily enough our team just introduced an eslint warning (https://github.com/eslint/eslint/blob/master/docs/rules/no-warning-comments.md https://github.com/eslint/eslint/blob/master/docs/rules/no-w...) to discourage those TODO comments as we found they just always sat around forever collecting lint.

noinsight 11y ago

Fossil is a great, simple system. It's especially good with Windows because (imo) it integrates much better than the others since it's just a single binary you can put in your $PATH. Git especially seems so hacky.

speps 11y ago

By the way, does anyone know of a SCM written in Go? It seems that the feature list of Fossil would fit Go pretty well, the networking/local web UI stuff for example, self-contained binary as well.

JustSomeNobody 11y ago
They should all be written in ANSI C. C90, specifically.
- falcolas 11y ago
  I appreciate the motivation behind this ideology, but giving up 26 years of advancement in programming languages (not to mention security and safety) for compatibility with a vanishingly small number of operating systems (few, if any, of which are in use as development machines) is not worth it for tools like these.

CodexArcanum 11y ago

I was introduced to Fossil through a previous HN post and I love it. For smaller personal projects, it's the best. I like that I can just put the repo file into Dropbox and then have my project's tickets, documentation, and code all in one place. And from someone who doesn't write much C, I will say that the source is very easy to read and poke around in. Just a great project all around.

sspiff 11y ago

I use Fossil for personal, private projects. I've never used it with other people. But being able to replicate the wiki, issues etc and version them is very cool. I use fossil to keep track of my code and use the wiki of a project as a scratchpad, design document, and general notes. I love it. It can be self-hosted using a super-simple CGI script: #!/usr/bin/fossil repository: /path/to/project/repository.fossil - which allows you to both clone over HTTP/HTTPS and access the Wiki and issue tracker via your browser. It has pretty decent access control and can allow you to configure a set of wiki pages to make read-only accessible to everyone, even when not logged in, to use as a project landing page for visitors. You can also customize the CSS of a project, which is also versioned in the single sqlite db backing a repository.

diego_moita 11y ago

Fossil is neat and the idea of a tickets tracker and wiki within the repo is very productive. However I got spoiled by the power of Git. So what I do now is to keep a TiddlyWiki[1] on the Git repo, so I have the best of both worlds. [1] http://tiddlywiki.com/ http://tiddlywiki.com/

wyoung2 11y ago
While I am a fan of chains of small cooperating tools, there is something to be said for a single large tool with a well-integrated feature set. Here are some of the advantages you get when the code repo, bug tracker, and wiki are all part of the same coherent system: 1. When a checkin fixes a bug noted in the ticket tracker, you can reference it in the checkin comment with a subset of the ticket ID: "Fixes [3b52b91fc]" That ticket ID becomes clickable in the web view of the timeline, taking you directly to the referenced ticket. Yes, I know, this is not a unique feature, but the other systems that have this also integrate the ticket tracker and code repo. The point is that you get this feature out of the box with Fossil, for free. 2. Your next step is to close the bug ticket. This modifies the appearance of the checkin comment you created in the previous step in the Fossil UI timeline view, rendering the ticket ID as strikethrough text, so you can see it refers to a closed ticket without clicking on it. The key point here is that the integration is bidirectional. (It would be even neater if Fossil would recognize the pattern "Fixes [artifact-ID]" in checkin comments and automatically close the ticket for you. It shouldn't be too difficult to add, since it's a unified system.) 3. Anywhere that Fossil accepts regular URLs, it will also accept artifact IDs. So, you can refer to checkins or tickets from the wiki, or from within a Markdown document checked into the code repo. 4. Because Fossil understands Markdown as one of its available wiki article formats, it can render Markdown documents in the code repo inside the Fossil UI when you click on them from the Files tab in the web UI. 5. That feature extends to other document types, too. This leads to the embedded documentation feature (http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki) which is a versioned alternative to the wiki. You use the wiki for articles that apply to all versions of the repository, or at least to the current trunk version. Where you instead need a given doc article to roll back to its historical content when you roll back the code, you want to use embedded documentation instead. You can use the wiki and embedded docs interchangeably, linking from one to the other, as needed.

node_uzer 11y ago

I'm a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I've customized the "fossil ui" to my liking. However, fossil does lacks some important features that svn, hg and git have: * Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. * Cannot perform a "fossil diff" for just a directory and its descendants - i.e., no fossil equivalent of the following: # produce a diff for this directory and its descendants git diff . * A "fossil merge" between distributed repos it will give commit attribution to the wrong user for all files in the merge - changes will be recorded as being made by the user performing the merge. This is particularly annoying because it makes "fossil blame" on a given file less effective when pinpointing who introduced what change. There are other fossil issues, but those are the biggest ones that come to mind.

jordigh 11y ago
> Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address. Hm? Neither git nor hg allow this either. The usual workaround in both is to put an placeholder file in the desired "empty" directory, such as a .gitignore.
- node_uzer 11y ago
  hg and svn support versioning directories. I assumed that git also did. If it does not, I stand corrected.
- node_uzer 11y ago
  You're also correct about hg not versioning empty directories with the default mercurial install. A previous place I worked had a non-standard extension - that unknown to me may very well have used the .keep file trick you described. So it would appear that fossil not supporting versioning of directories puts it in good SCM company.
11y ago