(1) Fossil was created for the single purpose of supporting SQLite development, a mission at which it has succeeded spectacularly. Fossil is therefore a success story, irregardless of its mind-share relative to Git. That thousands of other developers also find Fossil useful on their own project is just gravy. I am not concerned that Fossil has not (yet) become the "one true and great DVCS". My intent is to continue personally supporting and maintaining Fossil for at least three more decades.
(2) Git people: Please steal ideas and code from Fossil. This is not about winning and losing; it is about providing the best possible tools. Fossil has a number features which are missing from Git but which could be easily added to Git and would enhance the Git-user experience. I'm not talking about the philosophical differences between Fossil and Git (which I recognize that Git is unlikely to ever change) but rather specific UI features such as "fossil all" or "fossil ui" or "fossil undo" or the ability to view the ancestors of check-ins. Fossil is 2-clause BSD, so you do not even have to acknowledge where you stole the code from. Do it for your users, please.
Does Fossil have something like 'rollback'?
If not, would it not be good to have your standard SQL COMMIT/ROLLBACK semantics in an SCM?
I mean, sometimes you do something with your SCM that you immediately regret. Like, you do a 'pull' expecting that perhaps a couple files will be changed, and instead you get a screenful of statuses, errors and whatnots.
Ooops! So you look at what you typed, and turns out you were in a wrong branch, or you should have used 'pull x y' or whatever.
In any case, what you want to do now, is to 'roll back' ('undo') the last command.
Now, in SQL, when you make a mistake, you say 'rollback' and everything is good.
But in a typical SCM, either you cannot do it at all, or it is nontrivial. E.g. in Git, the way to 'undo' depends on the command that you are undoing. Sometimes it is 'revert', sometimes 'reset ^XX~xx' or 'abort', etc etc, clearly not optimal.
Is there an SCM that does that?
Fossil enforces the ethical principle that history, e.g., of a project, should not be revised after the fact. If broken code is submitted to the repo, it can be replaced, the prior code ignored, but it still is part of the project history, perhaps serving as a reminder of how things can go wrong, often a valuable lesson to pass along.
Projects are like people, we all have warts. We don't have to point them out to casual acquaintances, but we shouldn't try to pretend we don't have them at all.
Also, immutable history makes a lot of sense, not just for SCM, but for RDBMS, too.
So we see quite a few people are now going with the append-only databases.
Yes, but not like you mean. A commit is made using a SQLite transaction, so if any part of the commit process fails, it will roll the Fossil repo DB back to its prior state, preventing DB corruption. If you're synchronizing to a remote repository, a failure on the remote also rolls back changes to the local copy, too.
As for rolling back an already committed change, even DBMSes don't work like that. A Fossil commit is the same as SQL COMMIT: the transaction is committed now, and can't be backed out without a subsequent modification.
That said, a common way to get the effect you want with Fossil is to mark the bad commit as the start of a new branch, then resume work on the previously-damaged branch. Rather than delete history, this just pushes it off to the side, as a failed branch.
This does mean that if you make a bad commit, then make two more good commits on top of it, that moving the bad commit to an "ignored" branch will also move the two subsequent commits. However, Fossil also has a cherrypick feature that would let you apply the two good commits to the good branch.
You can sum Fossil vs Git up this way, in this regard: Git remembers what you should have done, Fossil remembers what you actually did.
Would it not be easier to just say "rollback"? Note that a "rollback" would apply just to the things changed since the last commit, just like in SQL. So then, by definition, you cannot rollback a commit. Just like in SQL.
Which SQL dialect are you using where you can ROLLBACK after COMMIT? That isn't ANSI SQL-92 or SQLite behavior. Quoting the standard:
> An SQL-transaction is terminated by a <commit statement> or a <rollback statement>.
Perhaps you were thinking of savepoints?
Hmm, reading about it, it looks like Mercurial's rollback "can be dangerous". That's kind of opposite of what you expect rollback to be.
Aside from that, I think all major vcs will allow you to clone "up to revision N" which in turn will give you a new repository that has been rolled back to N?
Whatever you comitted, you cannot rollback.
Or, say you have some unstaged changes, then accidentally issue a wrong pull or rebase or checkout, then rollback should affect just the pull/rebase/checkout, and get you back to where you had unstaged changes.
So there is no data loss in that scenario, as you can repeat the last command and get exactly the same result.
BTW I am not saying it cannot be done in a regular vcs, its just that it requires different command in different situations, and that obviously causes all kind of problems for many people.
Good to hear. This instill confidence in me for my continued use of both Fossil and the reason for its existence, SQLite. Thank you.
The web UI is great, and the bundled wiki/bug tracking works fine - but I never could get anonymous push/user registration to work smoothly enough for my needs (we're on a LAN, currently with bring-your-own-device and no central ldap/ad etc).
If it wasn't a group of 27 complete beginners (on Windows), I might have started people out with the basics of ssh and key generation - but in the end gogs had an easier start-up: single binary for me to deploy on a server, and git and vscode available for Windows via http://scoop.sh (as is Fossil :-)).
In the end things worked out - we spent more time on work process, the usual fight with git for a sane workflow (mercurial, Fossil and gitless all make it a bit easier to clone/branch/merge/push than git does. I really don't want too think to much when I rebase, and I don't want to detach my head).
The upside is that gogs is closer to the git/github workflow with git as the vcs tool and Web based "pull requests" -- which for better or worse has become standard.
And it became an opportunity to show that project management really is about people, communication, cooperation and process - not the tools.
We are always trying to make Fossil better. Can you explain what you mean by "anonymous push/user registeration" and provide more information on why it was a problem for you? Private email to firstname.lastname@example.org is ok for this.
I have 26 students, for whom I have no account information or central auth server (eg a typical "pop-up" workshop).
As everyone is new to programming and (d)Vcs, I would prefer some authorization help from the system (Fossil is pretty good here, afaik "git push --force" isn't really an issue).
Everyone are on Windows, and while ssh is available, it's not a great fit for the platform. Fossil has "fossil gui" and "fossil serve" which allow users to clone - but I never could get either: plain http (no ssl, as this isn't a public ip which complicates settling up a trusted cert a bit) with push from clients to work - with or without password.
With gogs, I could turn off the CAPTCHA and enable registration in the Web ui, and users could push with auth from git and visual studio code, using user/passwords.
As far as I got with Fossil was registering users that worked with the Web ui (eg: edit wiki) -- but I couldn't get sync (push to the server) to work (neither from Linux, nor Windows).
At first I thought it was an issue with a mix of Fossil versions, but in the end I think that ad-hoc LAN deployments just isn't all that we'll tested? Perhaps especially on/with Windows clients?
As far as I gather when cloning a repo, Fossil is supposed to get a copy of the user database, and so everyone should be able to a) use "fossil gui" and edit wiki pages etc and have changes auto-sync out of the box (assuming the upstream Fossil instance is up) and b) use "fossil serve" and have other registered users be able to push changes?
I was able to pull, and sync/push over ssh, but (auto)sync over http always failed. From the docs, it looks like it is supposed work, with a bit tuning of auth/authz settings in the administration Web ui).
Fossil as such does not need a central server; each user may just as well be self-sufficient, and if needed, to share his/her repo to other users (fossil server).
Still one easy way to accomplish the centralized setup is to designate one Fossil instance as the main/origin, create a repo, and launch 'fossil server', it will show the port on which it listens. Then make other users connect to the main by http://hostname:port.
To allow users to self-register, you need to log-in as admin-user and check an option in Admin::Access:Allow users to register themselves. Keep it checked at least until all of your users have registered. Make sure users have a Developer privilege, so that they can push the changes to the main repo.
This will add user names to the central repo, and will prompt for authorization at clone/commit/pull/push/update. In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`)
HTTP connect is fairly robust, with additional layer of security added on the Fossil's side to somewhat compensate for the clear-text login. Should suffice in trusted environment.
Your LAN should have no problems routing this as it's indeed a local traffic.
BTW, Fossil has a nice convenience feature called "autosync" which makes login/password use transparent, only enter it once and then all commits would automatically attempt to sync to origin repo. It can be turned-off in settings if not needed, on per-clone basis (fossil set autosync off)
Hope this helps.
I only ever got sync/push to work over ssh.
I might have tried having users pull changes from each other - but with 25+ students a central server/repo for resolving merge conflicts becomes necessary - not to mention that it would be hopeless for people new to the concept of version control in general and distributed vcs in particular.
Has anyone actually got auto-sync to work over http with Fossil of late?
fossil clone http://fossil-scm.org x.fossil
I have two guesses about what your problem was:
1. You didn't realize that Fossil normally listens on port 8080 by default, incrementing when it gets a bind failure, so that it could be on some higher port number, like 8082 if you have two other Fossil server instances running. If you need Fossil to bind to a specific port number, you need to pass -P to the "fossil server" command.
2. Your server machine's firewall blocks the Fossil listening port by default, and you didn't open it up.
Here's my "fossil server" wrapper script, which may help you the next time you try this:
if [ -n "$OLDPID" ]
echo "Killing old Fossil instance (PID $OLDPID) first..."
typeset -i i=1
while kill -0 $OLDPID > /dev/null 2>&1 && [ $i -lt 30 ]
if [ $i -eq 1 ]
echo -n "Waiting for it to die..."
fossil server -P 3691 --repolist /museum > /dev/null &
echo Fossil server running, PID $!.
It assumes your Fossils are stored in /museum — because where else would you keep fossils? — and that you like svnserve+1 as your Fossil port number. Adjust to taste.
To clone from such a server, say:
fossil clone http://myuser@myserver:3691/reponame reponame.fossil
[ed: I'm away from the computers I tested on, but I remember I found quite a few stories like this, which all seemed to be a few years old, and had no resolution:
Which is why I asked if anyone has been able to, with a current Fossil build, to:
On server "a" (in my case running Ubuntu 16.10, but testing both machines running Windows 10 would also be interesting): run fossil init ; fossil ui #change auth, register normal users user1, user2; fossil serve
Clone from a as user1, user2 on machine b with defined passwords (I got this far).
On b, run fossil ui, edit wiki as user1 and/or user2 - have sync work. Or edit and commit code and have sync work.
That sounds like your Fossil instance allows anonymous cloning but not anonymous checkins, and that you did not give a user name with the clone command, so that when you tried to check in a change (or sync, as you say) the remote server refused to accept the anonymous contribution.
Note in my examples above the `myuser@` part.
> I found quite a few stories like this...with no resolution
The specific one you pointed me to shows exactly the problem I describe above. The URL "http://pi:8193" gives a machine name and a port, but no user name.
Fossil will use your local user name as the Fossil user in some circumstances, but not in the clone command, because that signals an anonymous clone.
> Make sure users have a Developer privilege, so that they can push the changes to the main repo.
> In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`)
(although I'm fairly certain the error messages I got mentioned the correct user names. Is the bit about --admin-user in the Fossil docs?).
 "The construction was exceptionally challenging, at high altitudes in a region without roads and with a climate that saw many meters of snow in the winter and temperatures far below freezing. 113 tunnels, totaling 28 kilometres (17 mi) had to be built; the longest being the 5,311 metres (17,425 ft) Gravehalsen Tunnel, alone costing NOK 3 million and the longest tunnel north of the Alps. It took six years to build, and had to be excavated manually through solid gneiss."
With my latest project, I'm maintaining multiple splits of the codebase for different platform-specific features, and sharing the code with a team member. I was about to bite the bullet and start installing cvs or git in a VM and going through the learning curve, but this seems right up my alley and the kind of system I'd mesh with well. Thanks!
There's no such thing as too small: I use Git for everything, including small scripts I may never use again. The setup is "mkdir fooscript && cd fooscript && git init". Plus using GitLuBucket means free backups.
> But if a timestamp on a ticket change artifact is off by months or years, it can seriously confuse the replay algorithm for determining the current ticket state.
I understand the simplicity of merging all the ticket comments by timestamp, but couldn't they at least include a reference to one or more recent comments to help establish order when clocks are off? Still wouldn't avoid intentional bad actors, but there are bound to be people with misconfigured clocks.
If I'm working on a Fossil repository and I want to see what bugs everyone else has reported, where do I go to get a list of other copies of the repository so I can query them for new bug reports? Is there some kind of tracker that lists all the people currently publishing the same Fossil repository, so I can connect to each one and ask for updates?
I wrote a post  on my site about this concept recently. It's not really polished, I think the thoughts were incomplete. It was written in the context of git due to its ubiquity these days, but the concept should apply the same to other DVCS. I know I'm full of a lot of questions and few answers, but questions help me learn.
Pun not intended?
Let's step back a bit here, and realize that ticket tracking is typically one of the things you restrict access to in a Fossil repository. You're either running a private instance and have the whole repo locked down, or you're running a public instance and at least require a valid login before users are allowed to post tickets. The SQLite.org repo doesn't even allow normal users to post tickets; that feature is restricted to the core development team, with public-originating items going into the ticket tracker only after being discussed on the mailing list first.
(This policy also eliminates ticket spam.)
Therefore, the number of users that can confuse Fossil this way is small, and the Fossil server admin probably knows how to contact all of them.
Given that, the only way you're likely to confuse Fossil via this weakness is to have two people with clocks maybe a large fraction of an hour off both modifying the same ticket within an hour's span, so that the person with the bad clock appears to be making comments before the comments from other users. (Or vice versa if the clock error is in the future direction.)
So, we have an error case that can only happen among a small number of users, and only when someone isn't using NTP like they ought to, and then only when we have multiple users modifying a particular ticket in a small time window, and when it happens, it only causes a bit of web UI weirdness, not data corruption.
There's your answer, then: why spend much time fixing an extremely rare case with such minor consequences?
If it really bothers you, the Fossil project regularly accepts outside contribution patches.
> where do I go to get a list of other copies of the repository so I can query them for new bug reports?
You don't have to. Fossil syncs all artifacts back to the repo it cloned from, not just code artifacts. This includes not only tickets, but also wiki articles, etc.
The only weakness here is that Fossil's autosync feature doesn't happen on certain types of updates, including ticket changes, so you have two choices: manually say "fossil sync" to push ticket changes to the central repo, or wait until the next code commit, which will gather up the ticket changes and send those along with the code commit.
I don't know why Fossil doesn't autosync local ticket changes, but I'm sure it's purely a matter of development time and will, not a designed-in weakness. If you want remote fossils to autosync their local ticket changes, it should be easy to add the feature.
> Is there some kind of tracker that lists all the people currently publishing the same Fossil repository
In the context of your blog post, Fossil generally isn't run in the git "just fork me" mode of operation. It can run that way, but it's much more commonly used in the central-plus-clones model, where there is a canonical central repository and a working clone on each developer's machine.
This mode is encouraged by the Fossil autosync feature being turned on by default, which means each local checkin also syncs to the central repo.
You can turn autosync off, in which case Fossil works more like git, where a clone is allowed to go off on its own tangent relative to the repo it cloned from. However, that buys you many of the problems of Git relative to Fossil, such as that merging can be a pain. Autosync greatly increases the chance that any given commit will apply cleanly.
P.S: It's primary author is known for another piece of software that runs pretty much everywhere - SQLite!
If your experience was more than about half a year old, you might want to look at it again. The default skin changed recently to one that is much more of a modern web UI.
It is easy to switch the skin on an existing repository or to customize it to behave the way you like. Fossil currently ships with 10 distinct skins, by my count.
The problem of fossil UI is not a skin. Why that annoying commit hashes are so big? Do you really read them first? Take a look at github UI: every button and label have meaningful place and polished. And that is the problem of most github clones - they forgot to hire a designer.
In most places, Fossil shows an abbreviated form of the hash, typically 8-10 characters since Fossil, like Git, will accept any unique prefix of an artifact hash to refer to that artifact.
Here is a GitHub commit page:
This is a serious complaint?
> Do you really read them first?
No, you ignore them completely until you need to refer to one, and then you copy-paste it, just like with Git.
> every button and label have meaningful place and polished
Which button or label in the default Fossil skin is not in a meaningful place, and which shows a lack of polish? Be specific.
> they forgot to hire a designer.
I'm pretty sure the differences between the two stem not from forgetfulness but from the fact that GitHub, Inc. employs 608 people, is closed source, and has a revenue model, whereas Fossil is a side project of a company that's probably 1/100 that size and grows mainly by open source user code contributions.
That said, I'd love to see these features built as add-ons to git; it wouldn't be particularly difficult (no more difficult than developing a ticket tracker or a wiki independent of git). Then again, I'm uncomfortable with the repository dragging in lots of big stuff like screenshots and diagrams and such, which are very common for bug trackers and wikis and less common for code repositories (and something git historically didn't do well, anyway).
Perhaps having a separate git repo for each piece (source, bugs, wiki) and a convention of including links to them inside of special hidden file (like .gitignore) would be the right thing. But, then we don't have the issues and docs following the code around very closely, which gives up some of the positives.
But, out of the box, Fossil is a really nice looking system. If I weren't working with other people who already know git (which describes almost everyone everywhere), I'd probably give it a go. But, I am, so I won't.
Specifically regarding the ticket tracker, someone evaluating Fossil should realize that it is really flexible:
I don't mean to be rude or cast aspersions on you, but there's a lot of FUD like this surrounding Fossil. People look at multicolumn feature lists and see this one weird feature in one of the non-Fossil columns that has a check where Fossil doesn't and write Fossil off because they think they might need that feature. This kind of thinking is why there are so many 4x4 SUVs in the grocery store parking lot.
The simple fact is that there are a whole lot more relatively small software development teams than there are huge teams that really need a large fraction of the features in the large competing software packages.
Realize that I'm saying this about a DVCS that was designed to fit the needs of SQLite.org. If your team, code base, and community isn't larger than that of SQLite.org, it's "small" in this context, and can probably work happily within Fossil's limitations. Just as you won't be putting your Jeep Grand Cherokee in 4-Lo to get out of the parking lot, you probably don't actually need everything that, say, Bugzilla provides over Fossil's ticketing system.
Now, if you're comparing Fossil ticketing to Redmine + the Scrum dashboard plugin, and your project management is currently based on that workflow, that's a horse of a different color. But then, there's nothing preventing you from ignoring Fossil's ticketing feature and continuing to use your existing project management system.
My local workflow uses commit rewriting a lot in order to keep a useful history. I commit like crazy and then squash/reorder/rebase to make a nice logical history (http://gitup.co is awesome for this on OSX, BTW). I couldn't do this, at least at the time, with Fossil, and ended up with piles of not-very-useful commits.
Not only does working on a branch sequester each developer's individual insanities until merge time, it lets other team members keep an eye on that branch so there aren't big surprises when merge time comes around. We want both aspects, not just one or the other.
Back in the early days of computing, a programming team was likely to share a single expensive computer.
Then we had the PC revolution, so each developer could have his own computer, but we kept those devs in cube farms or similar shared working spaces, and they had a LAN to coordinate their work.
Then the Internet happened, and we started doing distributed development, so we invented Subversion and mailing lists and suchlike to give team members a way to coordinate their efforts.
Then we got DVCSes, which have their uses, but they cause a new problem, which is that they let developers fork the project and go off on a tangent, completely unmonitored. When they pop up weeks or months later with a new feature, that feature may not even merge cleanly, or if it does, it may not align with the core developers' vision of where the project is going. So, the fork is never healed, and you end up with a choice of forks, no better than old-style project forks, where the dissenters just copied the project repo.
This problem was solved in the Git world by Github, which effectively turns forks into a special kind of branch, in that you can trace forks from parent repos to children, and merge child forks back in just as easily as internal branches.
Fossil solves it differently by strongly encouraging a central-and-clones model: it helps maintain team cohesion in a distributed development environment. Fossil actively fights against users going off on a tangent. This is a good thing.
You can force Fossil to work like stock Git, but its default configuration fights against that, on purpose.
The combination of the BSD license and a self-contained C library in the style of sqlite that offers VCS capabilities app developers could build into their applications is extremely enticing. libgit2 (https://libgit2.github.com/) may have matured enough to be viable for that use case if one is comfortable with GPLv2 plus linking exception, but the sqlite-style include one header, build one C file and you're done integration is really really nice.
OTOH, it's competing with git, a very well-designed piece of software with ungodly marketing (and a terrible UI, and it was so well designed because McVoy's various projects had already made many of the mistakes that Git didn't, although it avoided some of Git's mistakes, so Linus had something to work off of. But that's not the point).
So, how can you tell that git is no good, if it is the best of the tools available?
One particular good feature is the concept of a commit phase. It makes is crystal clear when rewriting history is allowed, and more importantly, when it isn't.
Because the UI is complicated & confusing for new users, making it easy to dig yourself a hole.
The only struggle about svn is branching (copy the whole thing) and merging was more frequent. There were many CVS systems, which I worked on, where there was no way to track who made what change in a day.
The result is that I happily keep using Mercurial locally even when collaborating with people using Git. I don't see the need to have Mercurial specific hosting. (Well, until Bitbucket finally starts working with obsolence markers so I can use Changeset Evolution).
Would that have been fixed via reflog?
What other failures have there been?
To note, many heard about Fossil because of Zed Shaw, who was bitten by the bug, and wrote about leaving Fossil because of the data loss. I wonder, therefore, if your recollection is echoes of that one report.
Fossil users pipe up in HN comments, like https://news.ycombinator.com/item?id=12665875 from a day ago, https://news.ycombinator.com/item?id=12655740 from 3 days ago, and https://news.ycombinator.com/item?id=12622773 from a week ago, so there are active users.
Yes, uncommitted changes were lost, which is bad, but not at all what someone would think when you say "Fossil lost data."
Also, that particular problem was fixed more than five years ago.
> What other failures have there been?
I've been using Fossil for my main work repositories for over two years now, and have been monitoring the mailing list for about a year prior to that, and the only things even close to that that I can think of involve crazy user actions that confused Fossil into doing something odd, typically in the UI display only, which are now prevented at the code level.
Example: It is possible to fork the trunk by working offline — its autosync feature prevents it from happening when working online, connected to the repo you cloned from — but Fossil now demands that you heal the fork after turning autosync back on, so that you don't end up with multiple active "trunk" tips. After the trunk fork is healed, one branch becomes the "real" trunk, and the other looks like an unnamed branch that's now merged.
I'm not aware of any case of committed work being lost by Fossil. In every case where someone has managed to confuse Fossil, it's always been essentially a cosmetic issue, with all of the information necessary to get the repository back to a sane state available in the SQLite DB file.
I have personally never run into such a problem. The closest I've ever come to data loss with Fossil was purely due to ignorance.
(Briefly, Fossil UI was showing me one thing when I thought it was showing me something else, and since I didn't see what I expected to see, I thought it had lost data. This was purely a newbie misunderstanding.)
My hope was that plq would clarify either with a pointer or something else more than "IIRC".
The only thing I disagree with your assessment is that "ignorance" and "newbie misunderstanding" can sometimes be due to bad design, which is a design bug vs. an implementation bug. In the Shaw case, there was a bug in the code which widened the gap between the user model and how the code actually worked, and that gap did cause data loss, just not in committed data.
Also not in a way that could be handled in git with reflog, as plq suggested.
This is a more expansive definition of "bug" than software developers, who are often more focused on the implementation than the user interaction model and as XKCD points out are very good at memorizing arcane commands, typically use.
Hipp wrote that he might have done the same thing as Shaw, which means that specific case wasn't "purely a newbie misunderstanding."
I think that was a humble and magnanimous statement which cut off some of the blame-the-user flamewar that can all too often happen in developer-driven project. As I recall, Shaw noticed this, and thanked Hipp for the way he responded. I've tried to bear it in mind since then.
> Fossil uses a transactional database for local storage, meaning that the repository is protected from corruption even if a crash or power failure occurs in the middle of a commit. Extensive self-checks protect the repository from corruption from bugs. No work has ever been lost due to a software bug in Fossil.
I've never heard that Fossil could eat your data. I don't use it now, but I've tried it for a few personal projects and liked it.
2. Git is strictly worse than both Fossil and Monotone (two SQLite-based DVCSes I have used) w.r.t. losing _committed_ changes: it doesn't do any sync calls by default, and while their documentation confidently says that fsync is just a waste of time, POSIX guarantees are not enough for safety (ext3 guarantees are enough, btrfs are not — writes to two different files are not guaranteed to be ordered by default, and I have lost commits because of a power failure, and I haven't checked what guarantees ext4 provides there).
> To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing.
no software is perfect, but fossil uses sqlite under the hood and is developed by the author of sqlite. a fairly strong data integrity guarantee in my book.
Of course, mishaps happen, bugs too. Blaming SCM is easy, blaming no-backup habits, well, that's personal.
Fossil does get progressively more potent, I can attest to this on my user experience at least from v1.19 to v1.35. Many convenience features are added, yet core remains stable.
Was the the marketing of git basically due to the fact that Linus created it?
I'll give nitpick a go :)
I don't believe this should be such an obstacle, as most plugins implement only a part of SCM client features, thus asking you to resort to command-line for certain functions. Still, for a lot of developers the expected interaction with "everything" is through IDE. There seems to be a Git or SVN plugin for every possible IDE, yet Fossil lags in that department.
JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin.
We faced this with our Qt projects, and went on to develop a Fossil SCM plugin for QtCreator:
Not that availability of plugins has to be such a big deal for a SCM adoption, but sure this helps a lot to increase any SCM's visibility and accessibility. In case of Fossil this probably will have to be another community effort.
Collaborating, however, is an issue due to the prevalence of git (it was a bit easier in the Mercurial days because hg users were used to coexisting with something else).
The biggest advantage for me is having a single file as the repo. Makes it much easier to archive stuff.
It gained quite a bit of attention because Zed A. Shaw was bitten by it. Nevermind he didn't make a single commit for 3 days, or that he panicked, or that he didn't even make a simple "backup this folder so anything I do doesn't mess it up" as is standard with all other DVCS when something goes wrong. Fossil is fine in this regard, but a rebase function would be welcome.
I think everyone agreed that having an SCM on a project is a must. Everyone most likely is using some SCM already, often-times the choice is made by someone else upstairs or in the history. Git, bzr, hg, svn, TFS (ahem) -- you've just got to use what you've got.
HOWEVER, you may just as well use an SCM that is more __optimal__ for your development style, say, frequent commits, branching, stashes, private branches and then just pump the completed stages into "official" SCM -- kind of layering the version control.
You can install Git or bzr etc. just for yourself? Good!, but not everyone may have such a policy. Fossil does not require installation, it's a self-contained executable, you may just as well build it from source and use it in your account.
Just as simply, the same project directory may be tracked by Fossil in addition to the whatever is the "official" SCM, the only file it places in working dir is ".fslckout".
I think, there's really no need to debate and pit SCMs against each other -- just use what works for you, your project, well, what fits in your own memory (it's true, Fossil command and options set is very compact, yet potent -- check it out!)
Easy to export to a git repo too, e.g. to mirror to GitHub (which I do).
fossil export --git repo.fossil | git fast-import
1) Setup Git repo on GitHub.
2) Clone the Git repo.
3) Create local Fossil repo.
4) Add the cloned project to Fossil repo.
5) Work with Fossil.
6) Add/commit completed features to Git.
7) Push to GitHub.
8) Pull/Update respectively.
A bit of overhead, but for personal projects easy to get used to.
By that measure alone, about half of Fossil is "SQL", in the sense that more than half of the code merely manages the various DBs.
(A Fossil workspace consists of three SQLite DBs: the actual repo DB plus two machine-specific DBs, one local to the project and one global to the user login.)
There is a whole lot of embedded SQL among that C code. Simply counting the number of lines containing the 5 most common SQL statements:
That doesn't mean the total number of embedded SQL statements is the total of those 5 numbers, as some of that will be compound statements using two or more of the above keywords. Fossil uses some of the most complex SQL I've ever seen outside of http://thedailywtf.com/