4 ms·

Anyone using it for development? What is your experience?

by wirrbel 10y ago

rwbt 10y ago
I use fossil for all my projects. It's very lightweight and almost set it and forget it system. Remarkable.
rkeene2 10y ago
I use it a lot. Here are many of my repositories: http://chiselapp.com/user/rkeene/ http://chiselapp.com/user/rkeene/ I also use it for many non-public repositories, including the Linux distribution I maintain (with a few hundred packages). My experience is that it is very convenient and easy to adapt.
fundamental 10y ago
I started to use it for one large project a few months back as I liked the idea of having an integrated issue tracker/docs/wiki/etc. In the end I wasn't a huge fan of fossil overall as its implementation felt clunky and I reverted back to git. I'd say most of it's problems can be attributed to a lack of polish due to the much smaller user base compared to other options like git.
- rkeene2 10y ago
  What issues did you have ? Fossil is usually pretty easy to cleanup any dangling wires, if they can be coherently identified to people who may not see them in the same way as you.
  - fundamental 10y ago
    It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes (git add -p and vim's git-fugitive options make the staging area hugely useful); attaching files to issues/wiki/etc was difficult; setting up a remote which could be pushed/pulled from (with multiple machines) was difficult; and I recall the username + password combo failing in a way that I never diagnosed. Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
    - rkeene2 10y ago
      Many of these issues have likely been resolved. Wiki supports the wiki format, markdown, and HTML now. There is now a "fossil search" command for full-text search (including artifacts, if enabled). I've never had a username/password failure so no idea what that could be. For tickets, icomment is probably the solution you want but it's not very intuitive. git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.
lvh 10y ago
I've used it quite a bit, and I'm happy with it. My main gripe (and it's not much of a gripe): editor integration. There's vc-fossil, but vc incompatibly changed its API between Emacs24 and Emacs25. While I generally don't like git very much, magit is amazing (and, honestly, the only reason I can put up with git).
rbehrends 10y ago
I'm using it for a number of personal projects and a couple of projects with a small number of collaborators. Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for. Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.
- sqrt17 10y ago
  Numerical version numbers in Mercurial are a good thing until they start to differ in different repository copies, after which you have to educate everyone to refer to versions by their hash instead of the numeric version
  - rbehrends 10y ago
    1. You can use the Bzr approach instead, which has universally valid revision numbers. 2. Even local revision numbering has useful applications, such as annotate/blame, where numbers (unlike hashes) follow a chronological ordering. It is still better than not having them at all.

Anyone using it for development? What is your experience?

by wirrbel 10y ago

Anyone using it for development? What is your experience?

rwbt 10y ago

I use fossil for all my projects. It's very lightweight and almost set it and forget it system. Remarkable.

rkeene2 10y ago

I use it a lot. Here are many of my repositories: http://chiselapp.com/user/rkeene/ http://chiselapp.com/user/rkeene/ I also use it for many non-public repositories, including the Linux distribution I maintain (with a few hundred packages). My experience is that it is very convenient and easy to adapt.

fundamental 10y ago

I started to use it for one large project a few months back as I liked the idea of having an integrated issue tracker/docs/wiki/etc. In the end I wasn't a huge fan of fossil overall as its implementation felt clunky and I reverted back to git. I'd say most of it's problems can be attributed to a lack of polish due to the much smaller user base compared to other options like git.

rkeene2 10y ago
What issues did you have ? Fossil is usually pretty easy to cleanup any dangling wires, if they can be coherently identified to people who may not see them in the same way as you.
- fundamental 10y ago
  It's been a while, but I roughly recall: The formatting in the wiki was unusual; it was difficult to access wiki/doc/issues outside of the builtin webserver (for tickets I ended up building a TUI as a workaround https://github.com/fundamental/fs-tickets https://github.com/fundamental/fs-tickets (the original fossil repo is sitting around somewhere)); there was no 'fossil grep'; the lack of a staging area was annoying when sorting through exploratory changes (git add -p and vim's git-fugitive options make the staging area hugely useful); attaching files to issues/wiki/etc was difficult; setting up a remote which could be pushed/pulled from (with multiple machines) was difficult; and I recall the username + password combo failing in a way that I never diagnosed. Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
  - rkeene2 10y ago
    Many of these issues have likely been resolved. Wiki supports the wiki format, markdown, and HTML now. There is now a "fossil search" command for full-text search (including artifacts, if enabled). I've never had a username/password failure so no idea what that could be. For tickets, icomment is probably the solution you want but it's not very intuitive. git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.

lvh 10y ago

I've used it quite a bit, and I'm happy with it. My main gripe (and it's not much of a gripe): editor integration. There's vc-fossil, but vc incompatibly changed its API between Emacs24 and Emacs25. While I generally don't like git very much, magit is amazing (and, honestly, the only reason I can put up with git).

rbehrends 10y ago

I'm using it for a number of personal projects and a couple of projects with a small number of collaborators. Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for. Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.

sqrt17 10y ago
Numerical version numbers in Mercurial are a good thing until they start to differ in different repository copies, after which you have to educate everyone to refer to versions by their hash instead of the numeric version
- rbehrends 10y ago
  1. You can use the Bzr approach instead, which has universally valid revision numbers. 2. Even local revision numbering has useful applications, such as annotate/blame, where numbers (unlike hashes) follow a chronological ordering. It is still better than not having them at all.