Fossil got one very important idea right: the repo, wiki, bug tracker, and website are really all part of the same package.
Canonical tried to do with this launchpad and bzr, and Mercurial has a serviceable built-in webserver, but no one else really decided that all of these things were part of the same deal. Nowadays I guess gitlab comes closest, although it does keep git as a separate component, sort of.
I completely agree that having a one-stop web address for everything is incredibly useful, but honestly, the main benefit is deep cross-linking—and there are lots of other ways of achieving that. E.g., Phabricator is actually my favorite in this space: it provides a one-stop shop for bugs, boards (think Trello), asset management, password management, pre- and post-commit code reviews, CI, and more—and supports Mercurial, not just Git. (I’ve been incredibly impressed by its very low maintenance burden, too—something I think is really underrated when people consider their development tooling.) GitBucket, Redmine, Trac, and others would also fit the bill.
But Fossil’s insistence on making everything distributed causes some unique problems. E.g., what’s it mean to merge a bug if I edit it and you close it? Is it closed? Still opened? Reopened? Does your answer change if I tag a commit to the case? Etc. I think this is part of why Vault failed: the user model gets too complicated.
But Fossil’s insistence on making everything distributed causes some unique problems. E.g., what’s it mean to merge a bug if I edit it and you close it? Is it closed? Still opened? Reopened? Does your answer change if I tag a commit to the case? Etc. I think this is part of why Vault failed: the user model gets too complicated.
If bugs were a tracked object like code changes, the answer would be easy: user action would be required.
Also, this brings some nice advantages: if a dependency between the patch and the closing of the bug can be expressed (making it impossible to close the bug without merging the patch), at any point, your bug tracker is in sync with your code state.
Fossil got one very important idea right: the repo, wiki, bug tracker, and website are really all part of the same package.
I agree. It is very convenient to have all that features in one binary. I learnt about Fossil in 2010 listening to BSDTalk podcast #194. If I remember well, Richard Hipp talked about his intentions with Fossil: not to become the most popular VCS but serve as an example to others (maybe the popular ones) with its most innovative ideas. He created Fossil to scratch his itch: SQLite development version control. Curiosly enough, Fossil also uses SQLite under the hood.
Nah, SD is a far better model. Much like Fossil, it manages distributing a database to everyone, so it “feels” centralized, and the longer you’re offline, merely the more out of date your information and changes are.
I think the “put text files in git” model for bug tracking is a completely whacko way of tracking bugs, and produces really weird side effects. Software can definitely handle the syncing easily for information with this strict of semantics.
I was curious too, SD sounds like a good idea at least on the surface. However, it looks pretty dead, their mailing list is empty since 2013, and the repo is dusty: https://github.com/bestpractical/sd/tree/master
It still works, but the “connectors” have mostly bit-rotted (except for a version of the jira one I hacked up about 6 months ago to get working). It’s a very unfortunate end, for it could have been the chosen one :(
My biggest gripe with be was that it just dumped its database into git, in a format that wasn’t easily usable without the be tooling. Also, it didn’t use any of the particular features of the VC systems, e.g. making a patch a prerequisite for the closing of a bug (as described in my other comment), would have been easy in Darcs.
Fossil got one very important idea right: the repo, wiki, bug tracker, and website are really all part of the same package.
Canonical tried to do with this launchpad and bzr, and Mercurial has a serviceable built-in webserver, but no one else really decided that all of these things were part of the same deal. Nowadays I guess gitlab comes closest, although it does keep git as a separate component, sort of.
I completely agree that having a one-stop web address for everything is incredibly useful, but honestly, the main benefit is deep cross-linking—and there are lots of other ways of achieving that. E.g., Phabricator is actually my favorite in this space: it provides a one-stop shop for bugs, boards (think Trello), asset management, password management, pre- and post-commit code reviews, CI, and more—and supports Mercurial, not just Git. (I’ve been incredibly impressed by its very low maintenance burden, too—something I think is really underrated when people consider their development tooling.) GitBucket, Redmine, Trac, and others would also fit the bill.
But Fossil’s insistence on making everything distributed causes some unique problems. E.g., what’s it mean to merge a bug if I edit it and you close it? Is it closed? Still opened? Reopened? Does your answer change if I tag a commit to the case? Etc. I think this is part of why Vault failed: the user model gets too complicated.
One-stop shops are great, but I’ve never been a huge fan of Fossil-like designs.
If bugs were a tracked object like code changes, the answer would be easy: user action would be required.
Also, this brings some nice advantages: if a dependency between the patch and the closing of the bug can be expressed (making it impossible to close the bug without merging the patch), at any point, your bug tracker is in sync with your code state.
I agree. It is very convenient to have all that features in one binary. I learnt about Fossil in 2010 listening to BSDTalk podcast #194. If I remember well, Richard Hipp talked about his intentions with Fossil: not to become the most popular VCS but serve as an example to others (maybe the popular ones) with its most innovative ideas. He created Fossil to scratch his itch: SQLite development version control. Curiosly enough, Fossil also uses SQLite under the hood.
Here are two more recent interviews (2015):
[Comment from banned user removed]
Too bad the Bugs Everywhere project didn’t catch on. I wanted to see where it would go, especially seeing where Fossil went.
Nah, SD is a far better model. Much like Fossil, it manages distributing a database to everyone, so it “feels” centralized, and the longer you’re offline, merely the more out of date your information and changes are.
I think the “put text files in git” model for bug tracking is a completely whacko way of tracking bugs, and produces really weird side effects. Software can definitely handle the syncing easily for information with this strict of semantics.
Is SD still active? Also what are your experiences with it? The ability to sync between different existing bug tracking systems seems appealing to me.
I was curious too, SD sounds like a good idea at least on the surface. However, it looks pretty dead, their mailing list is empty since 2013, and the repo is dusty: https://github.com/bestpractical/sd/tree/master
It still works, but the “connectors” have mostly bit-rotted (except for a version of the jira one I hacked up about 6 months ago to get working). It’s a very unfortunate end, for it could have been the chosen one :(
That’s unfortunate (I was also interested to see how it worked out), but thanks for pointing SD out.
I’ve used the b extension for Mercurial a few years ago, before eventually switching back to a regular TODO file.
My biggest gripe with
bewas that it just dumped its database into git, in a format that wasn’t easily usable without thebetooling. Also, it didn’t use any of the particular features of the VC systems, e.g. making a patch a prerequisite for the closing of a bug (as described in my other comment), would have been easy in Darcs.I believe that Zed Shaw (of Mongrel fame) was a big fan of Fossil, at least until it somehow choked and caused him to lose a bunch of work: http://web.archive.org/web/20110810191918/http://sheddingbikes.com/posts/1306005291.html