Overview
Artifact ID: | 0efde4ca19973e760807eeed72daf1891332cd72e7dce4a1c96398a140af3b5d |
---|---|
Page Name: | Why Fossil? |
Date: | 2020-03-10 18:43:51 |
Original User: | joel |
Parent: | 9badc4c82838b942dd85129c823b8f8fc4059693428c8a07183d3a41e1ca5669 (diff) |
Content
Why Fossil?
Fossil provides version control, and like most hep developers I use version control because of its several benefits.
However, you are likely reading this because of the implied second half of the question: why Fossil and not Git?
- I want the source code to be part of the website. Fossil lets me do that easily, and lets me control the web interface, without running a database server or any third-party applications. Git doesn’t.
- The Fossil program is a single file and a Fossil repo is a single SQLite file. Deploying Fossil and moving repos around is dead-simple.
- For this project, I wanted granular control over how outside developers interact with the code: something between totally public or totally private. Fossil gives me very fine-grained permissions to apply to different individual users, types of accounts, or anonymous users.
- Fossil repos include bug tracking, embedded documentation, and wikis which are tightly integrated with the version-control functionality. This means all of my development notes and issue tracking are actually part my project, rather than objects hosted on a third-party service.
Being familiar with Git, you may find the following analogy statement instructive:
GitHub hosted repo : Self-hosted Fossil repo :: Expo floor booth : The Batcave
It’s a rough analogy, but it works.