6 ms·

The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems

by TheBoff 15y ago

The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems like bloated: they should be separate things, even if they're interconnected imo.

cpenner461 15y ago
This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
- iloveponies 15y ago
  The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
  - bch 15y ago
    The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
  - stonemetal 15y ago
    I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.
jamii 15y ago
The idea is to version control not just the code but the entire state of the project: bugs, documentation, discussion etc. I do think the implementation in fossil is a mistake though. If they had tied it to the code dag then you would be able to go back to any point in the project history and see the exact state of the project at that time.

by TheBoff 15y ago

cpenner461 15y ago

This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.

iloveponies 15y ago
The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
- bch 15y ago
  The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
- stonemetal 15y ago
  I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.

jamii 15y ago

The idea is to version control not just the code but the entire state of the project: bugs, documentation, discussion etc. I do think the implementation in fossil is a mistake though. If they had tied it to the code dag then you would be able to go back to any point in the project history and see the exact state of the project at that time.