http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...
> "fossil export | git fast-import" will get your stuff moved over efficiently. Thanks for hanging out with us. I expect you might come back to fossil someday, and if you do you will be welcomed.
Yep, that feature is awesome. :-) And yes, I think if it you come to me and say it's all stable now then I'd easily give it a try, but I have to be practical and get shit done.
In other words, it's nothing personal, just business.
After Fossil deleted its files he informs the maintainer of the bug, giving a clear description of what happened, and decides to switch to a more mainstream SCM.
I don't get why you're giving him so much heat. He seems to me constructive (the bug was fixed) and mature (he went to a more mainstream SCM that is less likely to have some kind of "never seen before" bug while you just "make a branch").
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.
Doesn't seem to be connected to reality. I've heard of Fossil and sqlite, but never of Shaw, who apparently wasn't even a commiter.
that was very possible the reason for his woes. Do not EVER manually edit the fossil repo db. That's like hex-editing an MS Word Doc.
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.or...
On the other hand fossil chose to store its artifacts in a SQL database because it makes interaction much much easier (it's just a SELECT; the SQL engine does the rest). Moreover, since fossil has access to a SQL database, it can cache a lot of information to make future extraction of information easier: instead of scanning the whole database on every read (or building a custom index as git does) you can create custom tables for your use case that point to the correct artifacts. Oh and SQLite is just an implementation detail, the real thing that matters is SQL.
So the real advantage of using SQL(ite) is in querying the data to produce all reports you want: list of commits/checkins, list of changes related to a file, list of issues linked to a given file, ...
That said, when you have an extremely simple data model and you have few different access patterns for which SQL wouldn't be of great use anyway, you can have your own file format as git does.
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?
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.
Edit: typo, grammar
If you use/would like to use fossil, you might also want to take a look at 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!)
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.
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".
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.
It's also possible to access everything in the repository using the command:
fossil sqlite3
[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.
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.
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.
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.
I'm interested what you think about BugsEverywhere ( http://bugseverywhere.org ), which keeps bug info in a hidden directory in the repo and integrates well with git. I've not used it before, but am considering it for a research project I've inherited which has no infrastructure (just source code in a zip file). I'd like to avoid proprietary hosting (eg. github) or hosting my own web server (eg. gitlab), so I'm thinking that BE would be a good fit, with hosting on gitorious.org
The demo of the Web UI gave a 502 so I couldn't access it and I don't have time to try it out locally right now..
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.
It was really promising but now seems more or less abandoned.
FWIW, I had also hoped Veracity would be developed further.
A shame, really, because they were at least trying new things in places.
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.
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.