Fossil SCM (from SQLite's creator)(fossil-scm.org)
fossil-scm.org
Fossil SCM (from SQLite's creator)
http://www.fossil-scm.org/
29 comments
One major downside: if Fossil has file move detection, I didn't find it.
i couldn't find it on the website, so i downloaded it and it does appear to support renaming files.
i couldn't find it on the website, so i downloaded it and it does appear to support renaming files.
jcs@smug:~/Downloads% ./fossil help mv
Usage: ./fossil mv|rename OLDNAME NEWNAME
or: ./fossil mv|rename OLDNAME... DIR
Move or rename one or more files within the treeYes, that's an explicit move. That's what I mean by informing the VCS that you renamed a file. It amounts to holding the VCS's hand and means that even trivial code rearrangements require considerable extra care, or explicit support for that precise VCS type from the IDE. Git and Mercurial autodetect moves, so you can freely use any regular tools you want to manipulate your files (command shell, Windows Explorer, Finder, IDE), and "git add -A" or "hg addremove" will properly record your changes.
Looks interesting. A lightweight (fully self-contained in one <2mb file) distributed version control system, with built-in wiki and bugtracker, written by the author of SQLite. Since it stores everything in SQLite, the entire repo can be copied around as one file, and solid transactions are already implemented. (It's probably quite portable.) It doesn't look like it has a library/API to use it as a storage backend, yet. Oh, and it's released under the GPL v. 2.
Word of warning: fossil open (checking out a project from the repo file) tarbombs the project into the current directory by default.
At a quick glance: it looks easy to use, the bug tracker and wiki look decent. It seems to be focused heavily on reliability (never corrupting the repo), at the possible expense of speed. It seemed slower than git, but likely still faster for day-to-day usage than non-distributed VCs. I don't have any pressing reason to switch from git, but I'm curious if anybody else here has comments from more than a few hours experience with it.
Word of warning: fossil open (checking out a project from the repo file) tarbombs the project into the current directory by default.
At a quick glance: it looks easy to use, the bug tracker and wiki look decent. It seems to be focused heavily on reliability (never corrupting the repo), at the possible expense of speed. It seemed slower than git, but likely still faster for day-to-day usage than non-distributed VCs. I don't have any pressing reason to switch from git, but I'm curious if anybody else here has comments from more than a few hours experience with it.
Sure, I've got a bunch, since I rather infamously screwed around with it after Eric Sink said it was the DVCS he was most interested in. In particular order:
Fossil wants to GPG-sign everything by default, and doesn't get along well with gnupg2. That means no gpg-agent, which means typing your password every time you make a commit.
Until recently, Fossil lacked private branches. Fossil now has private branches, with a twist: merging a private branch into a named branch shows up as a single commit, much as if you had qfold/git rebase -i'd them in Mercurial or Git. Multiple private branch support is still clumsy. Selectively pushing branches, as in Mercurial, is impossible.
Merging support is still very young. Fossil does not handle renaming a file in one branch and making changes in another at all; you'll lose either the changes, the rename, or both. Thankfully, the autosync feature, enabled by default, encourages you to stay rigorously up-to-date, lessening the chance of this occurring.
The SQLite schema still changes fairly often, so you'll need to "fossil rebuild all" fairly often, if you're keeping up-to-date.
Fossil is quite dependent on the integrated web server for using the tool. While most of the functionality is available from the command line, some isn't, and that which is, is frequently undocumented. The web interface, thankfully, is quite easy to use.
Fossil lacks any real patch management, which will be a disappointment for projects used to sending patches by email. It also lacks any support for git-diffs or similar, meaning that some changes stored by Fossil cannot be properly represented to the user.
I find Fossil's separation of repository from working directory highly annoying. Other users love it, and others don't care. Your mileage may vary.
I'm continuing to keep an eye on Fossil, if only because, with Mercurial and Git increasingly well-established, it's the only DVCS that brings anything remotely new to the table. That said, it's got a ways to go before I think it'll be of interest to most projects.
Fossil wants to GPG-sign everything by default, and doesn't get along well with gnupg2. That means no gpg-agent, which means typing your password every time you make a commit.
Until recently, Fossil lacked private branches. Fossil now has private branches, with a twist: merging a private branch into a named branch shows up as a single commit, much as if you had qfold/git rebase -i'd them in Mercurial or Git. Multiple private branch support is still clumsy. Selectively pushing branches, as in Mercurial, is impossible.
Merging support is still very young. Fossil does not handle renaming a file in one branch and making changes in another at all; you'll lose either the changes, the rename, or both. Thankfully, the autosync feature, enabled by default, encourages you to stay rigorously up-to-date, lessening the chance of this occurring.
The SQLite schema still changes fairly often, so you'll need to "fossil rebuild all" fairly often, if you're keeping up-to-date.
Fossil is quite dependent on the integrated web server for using the tool. While most of the functionality is available from the command line, some isn't, and that which is, is frequently undocumented. The web interface, thankfully, is quite easy to use.
Fossil lacks any real patch management, which will be a disappointment for projects used to sending patches by email. It also lacks any support for git-diffs or similar, meaning that some changes stored by Fossil cannot be properly represented to the user.
I find Fossil's separation of repository from working directory highly annoying. Other users love it, and others don't care. Your mileage may vary.
I'm continuing to keep an eye on Fossil, if only because, with Mercurial and Git increasingly well-established, it's the only DVCS that brings anything remotely new to the table. That said, it's got a ways to go before I think it'll be of interest to most projects.
> That means no gpg-agent, which means typing your password every time you make a commit.
Yikes. Monotone also made you do crypto auth setup upfront, which meant that starting up a new repository had a couple key/user-related steps that made it seem cumbersome compared to git or hg.
Yikes. Monotone also made you do crypto auth setup upfront, which meant that starting up a new repository had a couple key/user-related steps that made it seem cumbersome compared to git or hg.
For those interested, I found an answer to one of the less-frequently asked questions in a recent mailing list message.
Q. How large of an individual file is Fossil designed to comfortably work with?
A. Under 10 MB.
http://www.mail-archive.com/[email protected]...
So, as you would expect for an SQLite-backed system, it's only useful for source-code-sized files. Look elsewhere for archiving and versioning your data sources unless they're tiny (< 0.007% of a MacBook hard drive).
Q. How large of an individual file is Fossil designed to comfortably work with?
A. Under 10 MB.
http://www.mail-archive.com/[email protected]...
So, as you would expect for an SQLite-backed system, it's only useful for source-code-sized files. Look elsewhere for archiving and versioning your data sources unless they're tiny (< 0.007% of a MacBook hard drive).
When do you have files that large in a project?
Here are three:
* Sample data for test suites. I have single files of such larger than 21MB in my current project's git repo, and I've seen much bigger. * Audio resources. * Large PDF documentation items.
* Sample data for test suites. I have single files of such larger than 21MB in my current project's git repo, and I've seen much bigger. * Audio resources. * Large PDF documentation items.
Photoshop mockup of a page?
On one hand "don't store binaries" on the other, it's a work product for the project, and it makes sense to be stored and versioned.
On one hand "don't store binaries" on the other, it's a work product for the project, and it makes sense to be stored and versioned.
I suppose, I never really version control those, just track the revisions by uploading updates of the comps for the client, or using share drives if I'm working with other designers. I don't think you can merge PSDs, so many of the benefits of an SCM vanish.
I agree, you lose the merging when you work with binaries (for the most part).
But when I was at HP, our little team was behind the curve in tool use, and I was pushing for a comprehensive scm, instead of the patchwork we had. My big selling point was that given a stack of windows and database install disks, and the scm, you should be able to bootstrap the project up, and get it running.
I really like that point of view when it comes to SCMs. It's the official repository of everything project related. You have code, docs, graphics, everything needed. You do lose out on merging and stuff with binaries, but that's a small price to pay for the peace of mind you get.
But when I was at HP, our little team was behind the curve in tool use, and I was pushing for a comprehensive scm, instead of the patchwork we had. My big selling point was that given a stack of windows and database install disks, and the scm, you should be able to bootstrap the project up, and get it running.
I really like that point of view when it comes to SCMs. It's the official repository of everything project related. You have code, docs, graphics, everything needed. You do lose out on merging and stuff with binaries, but that's a small price to pay for the peace of mind you get.
Here is a working example of doing diff patches on PSDs.
http://www.codediesel.com/tools/transferring-psd-files-quick...
I've never tried it.
http://www.codediesel.com/tools/transferring-psd-files-quick...
I've never tried it.
Large SQL scripts, large images/video (I have one web app where the project is 1.3 GB), PSDs, PDFs, web apps that allow you download binaries (installers, software, etc...).
All in all, I'd say that 70% of projects I've worked on have had files in SVN that are bigger than 10 MB.
All in all, I'd say that 70% of projects I've worked on have had files in SVN that are bigger than 10 MB.
There are some nice ideas here, but it's too different from what I'm used to for me to use it full time (I use Git). I am interested if there is a way to get bug tracking and a wiki and store it in a git repo somewhere in the .git directory. Might be a nice feature for git 2.0 :)
Description, and what led me to submit this: http://news.ycombinator.com/item?id=809480
Any idea about performance, robustness, etc?
Very robust (SQLite, and it expects HTTP for transmission). Fairly performant, though not quite as fast as Git. I agree with the creator's take on this,
Fossil takes the philosophy of the tortoise: reliability is more important than raw speed. The developers of fossil see no merit in getting the wrong answer quickly.
http://www.fossil-scm.org/index.html/doc/tip/www/selfcheck.w...
The website also makes the bold claim on the homepage that
In over two years of operation, no work has ever been lost after having been committed to a Fossil repository.
Fossil takes the philosophy of the tortoise: reliability is more important than raw speed. The developers of fossil see no merit in getting the wrong answer quickly.
http://www.fossil-scm.org/index.html/doc/tip/www/selfcheck.w...
The website also makes the bold claim on the homepage that
In over two years of operation, no work has ever been lost after having been committed to a Fossil repository.
Fossil takes the philosophy of the tortoise: reliability is more important than raw speed. The developers of fossil see no merit in getting the wrong answer quickly.
Considering that Git and Hg are as reliable as Fossil (AFAIK) but faster, this sounds like an excuse.
Considering that Git and Hg are as reliable as Fossil (AFAIK) but faster, this sounds like an excuse.
I dunno what you consider reliable, but I don't trust git in the slightest. 3rd link down on a quick google search shows an august 2009 date (1st 2 links are both from 2006 on the git mailing list):
http://pastebin.ca/1549372
I've had git fuck with my code/data one too many times to fully trust it.
http://pastebin.ca/1549372
I've had git fuck with my code/data one too many times to fully trust it.
Could you flesh that out a little? Were they merges, broken commits, what? I haven't had problems with git, though perforce has gotten ugly for me on several times.
Looks like git-svn corruption, not git corruption.
That stinks. On one hand, the beauty of DVCS is that you can clone from another repos that isn't corrupt, but this would still be a big problem in a bare (central) repository during a merge or if you were working offline for an extended period of time (in which case you just lose your diffs). Of course we all keep local projects with just one copy of the repository.
One great thing about Fossil is how easy it is to back up since it's a single file. I've always felt that million-file approach was clumsy, even when centralized in a single directory.
One great thing about Fossil is how easy it is to back up since it's a single file. I've always felt that million-file approach was clumsy, even when centralized in a single directory.
Monotone (http://www.monotone.ca/ : a DVCS that predates git by several years, and was a major inspiration) keeps its repositories in SQLite databases, as well. I used it for a while, kept my home directory in mtn, etc. SQLite databases are indeed quite easy to back up. (You're better off putting "echo .dump | sqlite3 dbfile.sql > dbfile.sql.bak" in cron, though - the dump is more portable.)
Using SQLite dbs for serialization is a great idea, particularly for prototyping. It's not quite as efficient as bespoke file formats and data structures, but frequently good enough, and getting transactions for free is a huge bonus.
Using SQLite dbs for serialization is a great idea, particularly for prototyping. It's not quite as efficient as bespoke file formats and data structures, but frequently good enough, and getting transactions for free is a huge bonus.
One binary might be a good idea, but it seems like trac.edgewall.org is superior. Design and big community matters.
It's definitely pretty fast, although I didn't stress-test it. It noticed that I have GPG set up, and prompted me to sign all my commits by default. Very nice. It has no Git-style index, but commits straight to the repository like Mercurial. I did not find anything like "git add --patch" or darcs partial commits, so saving work seem to be all-or-nothing. Like any good modern VCS, Fossil seems to do real branching and merging, although I did not stress-test that, either.
One major downside: if Fossil has file move detection, I didn't find it. So you have to either spend some time informing it that you moved or renamed things (luckily, you can do this after the fact), or you need to use Fossil-aware tools.