10 ms·

Fossil – Simple, high-reliability, distributed software configuration management

128 points by typedweb 12y ago

jccooper 12y ago
I use fossil; like it a lot. If you use/would like to use fossil, you might also want to take a look at http://chiselapp.com http://chiselapp.com It's a bit github-ish; online repository hosting, private or public, and free. (I'd happily pay, but they don't provide even a donation page. So: thanks!)
- jrapdx3 12y ago
  Thanks for the link. I use Fossil for a few projects. While it's not too complicated to set up Fossil repositories on the web, the Chiselapp "hub" would make it even easier and probably a lot more reliable. One of the things to like about Fossil is its concept of record immutability, that is, data is retained intact in the database even when superseded by a newer version. Fossil asserts a highly ethical position, that revising historical facts is not an acceptable practice. Using Fossil over the last couple of years, its performance and stability have been rock solid, and I haven't experienced any data loss or other problems with it.
  - gioele 12y ago
    > One of the things to like about Fossil is its concept of record immutability, that is, data is retained intact in the database even when superseded by a newer version. Fossil asserts a highly ethical position, that revising historical facts is not an acceptable practice. There is big drawback in making it very hard to edit "history": you are bound to carry in your project all sorts of things that you do not want to. And this becomes an even worse problem when you combine source code, tickets and a wiki as Fossil does. Somebody posts spam as tickets? Now you are bound to have traces of that spam forever in your published repository. I switched away from bzr to git, just like many others, also because bzr made it impossible to fix small stupid mistakes. OK, I pressed Enter while reaching out for the shift key and made a commit with the wrong commit message. Why do I have to keep that? What does the project gains from this? I think the problem here is with the word "history". We attach a lot of meaning to that word and nobody wants to be a "history rewriter" or a "revisionist". I prefer more neutral terms like "patch queue" or "version chains". "I polished the chain" sounds much better than "I rewrote history".
    - Toenex 12y ago
      I agree that there is a difference between the actual history of a project and the writing of that history in a repository. We all make mistakes and rebase can be used to correct them. Fossil just takes the other view that we all make mistakes and we must live with them. I guess the choice of which to use very much depends on the circumstance. I use svn, hg and fossil choosing fossil more recently for my personal work for the simplicity of having code and wiki in a blob I can easily move. On a side note I'd probably refrain from using the phrase "polished the chain" due to the euphemistic nature of 'verb the noun' statements and my natural British tendency to avoid talking about sex explicitly and thus think everyone is talking about sex implicitly.
    - jrapdx3 12y ago
      In Fossil it's not impossible to remove offensive content, though deletion is discouraged. Fossil's policies and content removal procedures are discussed here: http://fossil-scm.org/index.html/doc/tip/www/shunning.wiki http://fossil-scm.org/index.html/doc/tip/www/shunning.wiki It's also possible to access everything in the repository using the command: fossil sqlite3 which opens a command line accepting sql queries. If one knows how to modify the database, then tickets, etc. can be edited. Probably, using the "official" methods to remove content is a lot safer.
      - sgbeal 12y ago
        FWIW: simply removing records from your repo db (in particular the blob table) _will_ corrupt it. Fossil stores deltas and other metadata which span blobs, and it's not trivial (and in many cases not possible) to separate them post facto. Hypothetically it would be possible to "pop" the top-most change from a repo, then repeat that, going all the way back to the start of the repo, but it's not possible to remove something from in the middle without the equivalent of a 4-way heart bypass surgery.
  - sgbeal 12y ago
    i've been working with/on Fossil since late 2007, and within the Fossil team we are not aware of _any_ loss of data except that caused by "system events" or severe user error (e.g. once i accidentally included a repo db in a sed filter, corrupting it).
    - dalke 12y ago
      What about https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04689.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... ? [Richard Hipp]: The bug that you hit had been there for ages - it wasn't new. But it was obscure. You were just the first to stumble over it. Sorry. The bug in this case caused a loss of uncommitted work.
Perceptes 12y ago
Zed Shaw uses Fossil in his Peepcode Play by Play episode. If you have a subscription to Peepcode (now Pluralsight[1]) you can listen to him talk about it and why he likes it. [1] http://www.pluralsight.com/ http://www.pluralsight.com/
- crazydoggers 12y ago
  And also why he stopped using it when it hosed his repo: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04671.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
  - sigzero 12y ago
    It did or he did?
    - isxek 12y ago
      There was a previous bug, and it was fixed then, but Zed decided eventually he can't afford to have it happen again (after losing 3 days of work) so he switched to Git. Richard Hipp (Fossil's author) was able to reconstruct what happened, more or less, here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
  - Leszek 12y ago
    I can understand the frustration of losing a couple of days of work, but wow, that thread does not show Zed Shaw in a good light. This approach of "there was a bug so now I'm throwing all my toys out of the pram" isn't particularly constructive or mature.
    - imanaccount247 12y ago
      >that thread does not show Zed Shaw in a good light It seems that Zed Shaw does not show Zed Shaw in a good light. That behavior appears to be the only kind he displays. A single bug that did not delete anything and all his work can be recovered with a single undo command and he wants so badly to turn it into drama, while insisting he's the only reason their program exists.
avodonosov 12y ago
I had this idea for years - to integrate wiki and tickets with source control. Probably I will like Fossil.
- chriswarbo 12y ago
  You might also like Trac ( http://trac.edgewall.org/ http://trac.edgewall.org/ ), which I've seen far more projects using than Fossil.
  - MrUnderhill 12y ago
    Trac is very different from Fossil though: Fossil is version control software with "embedded" wiki and issue tracker, while Trac is a wiki and issue tracker which can, optionally, interface with one or more external vcs systems. Fossil stores the wiki and issue data in the repository itself (SQLite), while Trac stores it in an external database (PostgreSQL, MySQL etc.. SQLite would probably work too!).
  - avodonosov 12y ago
    I don't mean an application with tickets, source control and wiki. I wanted to express (implement) tickets as wiki pages, and store them in source control; instead of 3 separate concepts. BTW, I don't like how trac tickets work - it's impossible to do agile (statistical) planning with them.
feld 12y ago
Sqlite uses this for their SCM. It makes sense as this is a good test of sqlite itself.
- grayclhn 12y ago
  It makes even more sense since it's the same developer.
  - feld 12y ago
    Indeed, I had forgotten about that :-)
- vince_refiti 12y ago
  And everything in Fossil is stored in SQLite, not flat files like most other systems. Seems weird at first, until you think about the advantage of storing things in an ACID database.
  - Touche 12y ago
    Can you expand, because I don't know what the advantage is. Other tools can access this information easily, is that you mean?
    - ludwigvan 12y ago
      Transaction support. No work is left midway. A Git repo might get corrupt in case of power failure. (Never experienced that though)
      - flogic 12y ago
        As far as I could tell at the time, I've had git fuck up on windows. I switched to the prod branch, did pull, and it merged the test branch into prod. Then, I deployed it, because I was in a hurry and didn't notice. Fortunately, it wasn't disastrous. That's when I switched back to using Linux as my primary dev environment.
chipsy 12y ago
I like using Fossil for my personal projects. I don't always use every feature, but it's all very small and self-contained and I can just copy the executable into the project root without having to worry about the system environment.
zachrose 12y ago
What do we mean by SCM? It seems to be that "software configuration management" should be about configuring a program, whereas "source code management" should be about managing source code. Which is Fossil?
- typedweb 12y ago
  The title was changed to something less accurate than what I originally posted.
- ludwigvan 12y ago
  You are right, makes it seem like this is for storing config files. Source code management is not enough though since this has built in issue tracker and wiki.
- forkandwait 12y ago
  It is weird -- I think SCM should mean "source control management" NOT "software configuration management", but the latter is what the website has.
- bch 12y ago
  "SCM" can stand for different words, depending who's uttering it, but where fossil stands is this: it fills the same role as git or mercurial. Its a DSCM (which I read as "distributed source control management"). Fill out the acronym as you see fit. Edit: typo, grammar
- jbostock 12y ago
  Source code management is a subset of software configuration management ("configuration" here refers to the configuration of the build rather than the end program). https://en.wikipedia.org/wiki/Software_configuration_management https://en.wikipedia.org/wiki/Software_configuration_managem...
- skrebbel 12y ago
  It's old school enterprise speak. When software-being-built consisted of a number of "Configuration Items" (CIs), such as .doc files, .xls files and of course heaps of .c files. There would be a dedicated "Configuration Manager" who's job it was to make sure that people wouldn't Visual SourceSafe their files over other people's files. He'd also write the batch files for the build server, assuming they had a build server. They really do mean source control. Just that it doesn't have to be source code. It can be any "configuration item". Just like with git or svn or mercurial or zipping-directories-and-uploading-them-to-a-network-share. Personally, I like "version control" for that reason. It just removes the subject of the operation from the name entirely.
ossreality 12y ago
High reliability? Didn't the main Fossil dev experience serious data loss while using fossil just a year or two ago?
hendry 12y ago
Looks crazy compared to checking /etc into git.
- untothebreach 12y ago
  Fossil is a general-purpose SCM tool, just like git, just with more features (integrated bug tracker, etc), so in theory you _could_ check /etc/ in to fossil as well.
  - sgbeal 12y ago
    Fossil is not the right job for that - there's a dozen entries in the ML archives explaining why. Short version: it doesn't do file permissions and system users, and many files in /etc require specific perms and owners.
    - untothebreach 12y ago
      Thanks for the correction, my knowledge of fossil is very shallow
stephenr 12y ago
I'm all-for supporting alternative solutions, particularly in the VCS space. SVN is not great for some tasks, but for some its still superior. Git is very popular but still not ideal for some workflows/project types. Mercurial is oftentimes a more approachable alternative to Git, but has less mindshare. Personally I think variety should be embraced. Let each project use the VCS that works for it's specific needs/developers. With this mindset, while I would have no issue supporting and making use of something like Fossil (assuming it's reliable), I would absolutely discourage the use of it's wiki and ticket systems, in favour of independent solutions that are not tied to the repo and repo software itself.
- andrewflnr 12y ago
  That last statement needs more justification. Tickets, in particular, are fundamentally tied to the code base. There are lots of things you could use the wiki for, like internal API documentation, that are just a step above in-code comments. Why on earth shouldn't they be stored in the same system with the code, especially when that arrangement simplifies the setup needed to start working on the project?
  - stephenr 12y ago
    Code base !== One repo. I agree for some projects this all-in-one system might be beneficial, I'm saying personally I would expect teams to use standard tools for tasks. A wiki and ticket system that works the same regardless of the type of repo you use. Im looking at this from the point of view of providing infrastructure for teams to work on different projects. A project does not necessarily mean a single repo.
    - cakoose 12y ago
      Fossil's bug tracker is not just a separate system bundled with Fossil. The bug database is integrated with the VCS for a reason. Edits to the bug database are tracked, branched, and merged the same way source code is. For example, let's say you create a branch to work on a new bug fix. In that branch, you make the fix to the source code, and modify the bug status to "fixed". When you merge your branch back into trunk, both the code fix and bug status get merged atomically. It definitely is possible to create a bug tracker that did these things but was still separate from the VCS. I remember seeing some early-stage bug trackers that stored all bug data as files in the repository (instead of in a separate database) and could be made to work with multiple VCS backends easily. However, since VCSes weren't designed for this, it was sort of of clunky to use. Ideally, there would be some interface between VCS and bug tracker to make sure they're decoupled but still work well together, but nobody has figured out that interface yet. Until someone does, it's much simpler for Fossil to ignore the coupling issue for now and focus instead on making the best product they can.
pm 12y ago
I used Fossil for a while, and I liked it a lot. But after using it with my team, and having to host it internally (something I didn't have the time to do properly being a startup), and programmers complaining about the conflict resolution process, we moved our projects over to git/GitHub. Honestly, I haven't looked back, even though I much preferred Fossil's simplicity.
- networked 12y ago
  Can you elaborate on the problems you had with conflict resolution? I used Fossil for a couple of personal projects and made a mental note to try it out instead of Git next time I had to host a code repository on a local server.
- sgbeal 12y ago
  "...complaining about the conflict resolution process..." In Fossil? Absurd. i don't know that i have ever, without help from a git professional, successfully resolved a merge conflict in git. In fossil it's trivial.
mrmondo 12y ago
The first thing I notice is how ugly the website is - if this reflects at all upon how ugly the scm is (and it may well not), the it's not going to gain traction.
- hollerith 12y ago
  Ugliness is subjective: I really liked it, or more precisely, nothing about it annoyed me, and many of the design decisions on the web these years annoy me. You got me curious what exactly about it struck you as ugly. (You could reply to my email, which is in my profile, if you are worried about getting downvoted.)
  - sgbeal 12y ago
    i suspect he's talking about the general aesthetics of the UI. None of the developers (and i'm allowed to say this, being one of them ;) has demonstrated a particular gift for making apps look really pretty.
reitanqild 12y ago
Since so many smart people interested in DVCS are looking anyway: anyone knows whats happening to veracity scm? QA has been offline for months. It was really promising but now seems more or less abandoned.
- durin42 12y ago
  As far as I know, veracity is no longer developed. The list has been dead for a long time (last post over a year ago), and the last release is 20 months old. A shame, really, because they were at least trying new things in places.
- isxek 12y ago
  I can't find it anymore, but Eric Sink (SourceGear) wrote sometime previously on his blog that they've decided to focus more on the mobile market with a product called Zumero (http://zumero.com/ http://zumero.com/). IIRC Zumero came from all their work on Veracity. FWIW, I had also hoped Veracity would be developed further.
deleted 12y ago
[deleted]
beagle3 12y ago
A bit of history: DR Hipp, who created SQLite, created a wonderful bug tracking system and wiki for it, called CVSTrac, with the moto "low ceremony defect tracking" that was tied to CVS. It was wonderful - I had used it in my CVS days. It was written in C, based on SQLite, was fast and just worked. Trac was inspired by CVSTrac, but is written in Python, is not tied to CVS, is slower but much more capable and much more flexible (although still "low ceremony" compared to e.g. Bugzilla). Fossil is DR Hipp's version control system, which integrates content version tracking, wiki and issue tracking (low ceremony CVSTrac-alike adapted for fossil) I haven't had a chance to use it - last time I looked at it, it was missing crypto parts that are essential in some of the projects I work on. But if Fossil gets crypto done right, or if I stop needing it done right, I will definitely give fossil a try.

128 points by typedweb 12y ago

I use fossil; like it a lot. If you use/would like to use fossil, you might also want to take a look at http://chiselapp.com http://chiselapp.com It's a bit github-ish; online repository hosting, private or public, and free. (I'd happily pay, but they don't provide even a donation page. So: thanks!)

jrapdx3 12y ago
Thanks for the link. I use Fossil for a few projects. While it's not too complicated to set up Fossil repositories on the web, the Chiselapp "hub" would make it even easier and probably a lot more reliable. One of the things to like about Fossil is its concept of record immutability, that is, data is retained intact in the database even when superseded by a newer version. Fossil asserts a highly ethical position, that revising historical facts is not an acceptable practice. Using Fossil over the last couple of years, its performance and stability have been rock solid, and I haven't experienced any data loss or other problems with it.
- gioele 12y ago
  > One of the things to like about Fossil is its concept of record immutability, that is, data is retained intact in the database even when superseded by a newer version. Fossil asserts a highly ethical position, that revising historical facts is not an acceptable practice. There is big drawback in making it very hard to edit "history": you are bound to carry in your project all sorts of things that you do not want to. And this becomes an even worse problem when you combine source code, tickets and a wiki as Fossil does. Somebody posts spam as tickets? Now you are bound to have traces of that spam forever in your published repository. I switched away from bzr to git, just like many others, also because bzr made it impossible to fix small stupid mistakes. OK, I pressed Enter while reaching out for the shift key and made a commit with the wrong commit message. Why do I have to keep that? What does the project gains from this? I think the problem here is with the word "history". We attach a lot of meaning to that word and nobody wants to be a "history rewriter" or a "revisionist". I prefer more neutral terms like "patch queue" or "version chains". "I polished the chain" sounds much better than "I rewrote history".
  - Toenex 12y ago
    I agree that there is a difference between the actual history of a project and the writing of that history in a repository. We all make mistakes and rebase can be used to correct them. Fossil just takes the other view that we all make mistakes and we must live with them. I guess the choice of which to use very much depends on the circumstance. I use svn, hg and fossil choosing fossil more recently for my personal work for the simplicity of having code and wiki in a blob I can easily move. On a side note I'd probably refrain from using the phrase "polished the chain" due to the euphemistic nature of 'verb the noun' statements and my natural British tendency to avoid talking about sex explicitly and thus think everyone is talking about sex implicitly.
  - jrapdx3 12y ago
    In Fossil it's not impossible to remove offensive content, though deletion is discouraged. Fossil's policies and content removal procedures are discussed here: http://fossil-scm.org/index.html/doc/tip/www/shunning.wiki http://fossil-scm.org/index.html/doc/tip/www/shunning.wiki It's also possible to access everything in the repository using the command: fossil sqlite3 which opens a command line accepting sql queries. If one knows how to modify the database, then tickets, etc. can be edited. Probably, using the "official" methods to remove content is a lot safer.
    - sgbeal 12y ago
      FWIW: simply removing records from your repo db (in particular the blob table) _will_ corrupt it. Fossil stores deltas and other metadata which span blobs, and it's not trivial (and in many cases not possible) to separate them post facto. Hypothetically it would be possible to "pop" the top-most change from a repo, then repeat that, going all the way back to the start of the repo, but it's not possible to remove something from in the middle without the equivalent of a 4-way heart bypass surgery.
- sgbeal 12y ago
  i've been working with/on Fossil since late 2007, and within the Fossil team we are not aware of _any_ loss of data except that caused by "system events" or severe user error (e.g. once i accidentally included a repo db in a sed filter, corrupting it).
  - dalke 12y ago
    What about https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04689.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... ? [Richard Hipp]: The bug that you hit had been there for ages - it wasn't new. But it was obscure. You were just the first to stumble over it. Sorry. The bug in this case caused a loss of uncommitted work.

Perceptes 12y ago

Zed Shaw uses Fossil in his Peepcode Play by Play episode. If you have a subscription to Peepcode (now Pluralsight[1]) you can listen to him talk about it and why he likes it. [1] http://www.pluralsight.com/ http://www.pluralsight.com/

crazydoggers 12y ago
And also why he stopped using it when it hosed his repo: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04671.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
- sigzero 12y ago
  It did or he did?
  - isxek 12y ago
    There was a previous bug, and it was fixed then, but Zed decided eventually he can't afford to have it happen again (after losing 3 days of work) so he switched to Git. Richard Hipp (Fossil's author) was able to reconstruct what happened, more or less, here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
- Leszek 12y ago
  I can understand the frustration of losing a couple of days of work, but wow, that thread does not show Zed Shaw in a good light. This approach of "there was a bug so now I'm throwing all my toys out of the pram" isn't particularly constructive or mature.
  - imanaccount247 12y ago
    >that thread does not show Zed Shaw in a good light It seems that Zed Shaw does not show Zed Shaw in a good light. That behavior appears to be the only kind he displays. A single bug that did not delete anything and all his work can be recovered with a single undo command and he wants so badly to turn it into drama, while insisting he's the only reason their program exists.

avodonosov 12y ago

I had this idea for years - to integrate wiki and tickets with source control. Probably I will like Fossil.

chriswarbo 12y ago
You might also like Trac ( http://trac.edgewall.org/ http://trac.edgewall.org/ ), which I've seen far more projects using than Fossil.
- MrUnderhill 12y ago
  Trac is very different from Fossil though: Fossil is version control software with "embedded" wiki and issue tracker, while Trac is a wiki and issue tracker which can, optionally, interface with one or more external vcs systems. Fossil stores the wiki and issue data in the repository itself (SQLite), while Trac stores it in an external database (PostgreSQL, MySQL etc.. SQLite would probably work too!).
- avodonosov 12y ago
  I don't mean an application with tickets, source control and wiki. I wanted to express (implement) tickets as wiki pages, and store them in source control; instead of 3 separate concepts. BTW, I don't like how trac tickets work - it's impossible to do agile (statistical) planning with them.

feld 12y ago

Sqlite uses this for their SCM. It makes sense as this is a good test of sqlite itself.

grayclhn 12y ago
It makes even more sense since it's the same developer.
- feld 12y ago
  Indeed, I had forgotten about that :-)
vince_refiti 12y ago
And everything in Fossil is stored in SQLite, not flat files like most other systems. Seems weird at first, until you think about the advantage of storing things in an ACID database.
- Touche 12y ago
  Can you expand, because I don't know what the advantage is. Other tools can access this information easily, is that you mean?
  - ludwigvan 12y ago
    Transaction support. No work is left midway. A Git repo might get corrupt in case of power failure. (Never experienced that though)
    - flogic 12y ago
      As far as I could tell at the time, I've had git fuck up on windows. I switched to the prod branch, did pull, and it merged the test branch into prod. Then, I deployed it, because I was in a hurry and didn't notice. Fortunately, it wasn't disastrous. That's when I switched back to using Linux as my primary dev environment.

chipsy 12y ago

I like using Fossil for my personal projects. I don't always use every feature, but it's all very small and self-contained and I can just copy the executable into the project root without having to worry about the system environment.

zachrose 12y ago

What do we mean by SCM? It seems to be that "software configuration management" should be about configuring a program, whereas "source code management" should be about managing source code. Which is Fossil?

typedweb 12y ago
The title was changed to something less accurate than what I originally posted.
ludwigvan 12y ago
You are right, makes it seem like this is for storing config files. Source code management is not enough though since this has built in issue tracker and wiki.
forkandwait 12y ago
It is weird -- I think SCM should mean "source control management" NOT "software configuration management", but the latter is what the website has.
bch 12y ago
"SCM" can stand for different words, depending who's uttering it, but where fossil stands is this: it fills the same role as git or mercurial. Its a DSCM (which I read as "distributed source control management"). Fill out the acronym as you see fit. Edit: typo, grammar
jbostock 12y ago
Source code management is a subset of software configuration management ("configuration" here refers to the configuration of the build rather than the end program). https://en.wikipedia.org/wiki/Software_configuration_management https://en.wikipedia.org/wiki/Software_configuration_managem...
skrebbel 12y ago
It's old school enterprise speak. When software-being-built consisted of a number of "Configuration Items" (CIs), such as .doc files, .xls files and of course heaps of .c files. There would be a dedicated "Configuration Manager" who's job it was to make sure that people wouldn't Visual SourceSafe their files over other people's files. He'd also write the batch files for the build server, assuming they had a build server. They really do mean source control. Just that it doesn't have to be source code. It can be any "configuration item". Just like with git or svn or mercurial or zipping-directories-and-uploading-them-to-a-network-share. Personally, I like "version control" for that reason. It just removes the subject of the operation from the name entirely.

ossreality 12y ago

High reliability? Didn't the main Fossil dev experience serious data loss while using fossil just a year or two ago?

hendry 12y ago

Looks crazy compared to checking /etc into git.

untothebreach 12y ago
Fossil is a general-purpose SCM tool, just like git, just with more features (integrated bug tracker, etc), so in theory you _could_ check /etc/ in to fossil as well.
- sgbeal 12y ago
  Fossil is not the right job for that - there's a dozen entries in the ML archives explaining why. Short version: it doesn't do file permissions and system users, and many files in /etc require specific perms and owners.
  - untothebreach 12y ago
    Thanks for the correction, my knowledge of fossil is very shallow

stephenr 12y ago

I'm all-for supporting alternative solutions, particularly in the VCS space. SVN is not great for some tasks, but for some its still superior. Git is very popular but still not ideal for some workflows/project types. Mercurial is oftentimes a more approachable alternative to Git, but has less mindshare. Personally I think variety should be embraced. Let each project use the VCS that works for it's specific needs/developers. With this mindset, while I would have no issue supporting and making use of something like Fossil (assuming it's reliable), I would absolutely discourage the use of it's wiki and ticket systems, in favour of independent solutions that are not tied to the repo and repo software itself.

andrewflnr 12y ago
That last statement needs more justification. Tickets, in particular, are fundamentally tied to the code base. There are lots of things you could use the wiki for, like internal API documentation, that are just a step above in-code comments. Why on earth shouldn't they be stored in the same system with the code, especially when that arrangement simplifies the setup needed to start working on the project?
- stephenr 12y ago
  Code base !== One repo. I agree for some projects this all-in-one system might be beneficial, I'm saying personally I would expect teams to use standard tools for tasks. A wiki and ticket system that works the same regardless of the type of repo you use. Im looking at this from the point of view of providing infrastructure for teams to work on different projects. A project does not necessarily mean a single repo.
  - cakoose 12y ago
    Fossil's bug tracker is not just a separate system bundled with Fossil. The bug database is integrated with the VCS for a reason. Edits to the bug database are tracked, branched, and merged the same way source code is. For example, let's say you create a branch to work on a new bug fix. In that branch, you make the fix to the source code, and modify the bug status to "fixed". When you merge your branch back into trunk, both the code fix and bug status get merged atomically. It definitely is possible to create a bug tracker that did these things but was still separate from the VCS. I remember seeing some early-stage bug trackers that stored all bug data as files in the repository (instead of in a separate database) and could be made to work with multiple VCS backends easily. However, since VCSes weren't designed for this, it was sort of of clunky to use. Ideally, there would be some interface between VCS and bug tracker to make sure they're decoupled but still work well together, but nobody has figured out that interface yet. Until someone does, it's much simpler for Fossil to ignore the coupling issue for now and focus instead on making the best product they can.

pm 12y ago

I used Fossil for a while, and I liked it a lot. But after using it with my team, and having to host it internally (something I didn't have the time to do properly being a startup), and programmers complaining about the conflict resolution process, we moved our projects over to git/GitHub. Honestly, I haven't looked back, even though I much preferred Fossil's simplicity.

networked 12y ago
Can you elaborate on the problems you had with conflict resolution? I used Fossil for a couple of personal projects and made a mental note to try it out instead of Git next time I had to host a code repository on a local server.
sgbeal 12y ago
"...complaining about the conflict resolution process..." In Fossil? Absurd. i don't know that i have ever, without help from a git professional, successfully resolved a merge conflict in git. In fossil it's trivial.

mrmondo 12y ago

The first thing I notice is how ugly the website is - if this reflects at all upon how ugly the scm is (and it may well not), the it's not going to gain traction.

hollerith 12y ago
Ugliness is subjective: I really liked it, or more precisely, nothing about it annoyed me, and many of the design decisions on the web these years annoy me. You got me curious what exactly about it struck you as ugly. (You could reply to my email, which is in my profile, if you are worried about getting downvoted.)
- sgbeal 12y ago
  i suspect he's talking about the general aesthetics of the UI. None of the developers (and i'm allowed to say this, being one of them ;) has demonstrated a particular gift for making apps look really pretty.

reitanqild 12y ago

Since so many smart people interested in DVCS are looking anyway: anyone knows whats happening to veracity scm? QA has been offline for months. It was really promising but now seems more or less abandoned.

durin42 12y ago
As far as I know, veracity is no longer developed. The list has been dead for a long time (last post over a year ago), and the last release is 20 months old. A shame, really, because they were at least trying new things in places.
isxek 12y ago
I can't find it anymore, but Eric Sink (SourceGear) wrote sometime previously on his blog that they've decided to focus more on the mobile market with a product called Zumero (http://zumero.com/ http://zumero.com/). IIRC Zumero came from all their work on Veracity. FWIW, I had also hoped Veracity would be developed further.

deleted 12y ago

[deleted]

beagle3 12y ago

A bit of history: DR Hipp, who created SQLite, created a wonderful bug tracking system and wiki for it, called CVSTrac, with the moto "low ceremony defect tracking" that was tied to CVS. It was wonderful - I had used it in my CVS days. It was written in C, based on SQLite, was fast and just worked. Trac was inspired by CVSTrac, but is written in Python, is not tied to CVS, is slower but much more capable and much more flexible (although still "low ceremony" compared to e.g. Bugzilla). Fossil is DR Hipp's version control system, which integrates content version tracking, wiki and issue tracking (low ceremony CVSTrac-alike adapted for fossil) I haven't had a chance to use it - last time I looked at it, it was missing crypto parts that are essential in some of the projects I work on. But if Fossil gets crypto done right, or if I stop needing it done right, I will definitely give fossil a try.