Original author of Fossil here, with two comments:
(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.
The fact that you created both an SCM, and a RDBMS, kind of forces the question:
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.
Fossil does have an undo command but that doesn't work on commits (checkin). It works on update and revert. Also thete is no rebase to edit the history. Once you commit it's there. You just mark the bad commit as a mistake or commit changes in the following checkin. Stuff never gets deleted from the repo but there is a scrub command. All of this encourages one to commit responsibly.
That's interesting an idea in Fossil that I've always assumed was borrowed from database ideology. When data is committed to a database and other data depends on it, deleting data risks damaging data integrity, let alone issues of falsifying the record.
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.
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.
> 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
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.
Mercurial has a 'rollback' command, which they've marked as deprecated a few months (years?) ago, but you can still use it when you reach a tight spot.
In a vcs it seems natural that rollback is dangerous - it should be the only way to delete work? The only alternative would be to stash what is rolled back in a branch, or somewhere else on disk? At witch point it isn't really a rollback anymore?
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?
Right, but I was talking specifically SQL-like semantics.
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.
Never heard of it before, but I'm grateful to hear about it! My projects were always small enough that a traditional version control system wasn't worth the time to set up. Just keep an archive of each day's progress in a folder and call it done.
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!
> My projects were always small enough that a traditional version control system wasn't worth the time to set up
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.
It's really easy to use and it has builtin help like mercurial. No need to read man pages. We use it for all our projects. I also use it for tracking config changes in /etc.
I had hoped to use Fossil for a new class I'm teaching, but ended up using a combination of gogs (and git).
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.
> I never could get anonymous push/user registration to work smoothly....
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 drh@sqlite.org is ok for this.
The easiest way to explain this is probably through my scenario (and an example of how gogs worked, where Fossil fell a little short):
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).
Seems like you were trying to create a centralized server, akin to GitHub or ChiselApp to serve as a main repo and registration site, allowing users to self-register.
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)
I very much wanted/needed a "distributed/centralised" model - everyone is working on the same repo. I never did get sync/push to work - I could pull down repo and wiki, but neither code nor wiki changes would auto-sync over http - I forget the exact error I got, but it seemed others had come across the issue in older versions - the suggested fix was to make sure server and client was on the same version of Fossil - due to some change in handling of storing usernames and password hashes - but this was in a version quite a few point-releases older than the oldest binary I tried. And I also tried with latest stable with a pristine repo.
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?
It's hard to know what your problems are from such a vague description, but I've been using Fossil over HTTP on private LANs for years now. I only use Fossil over SSH when I need to tunnel to a remote server that can't forward HTTP out to where the client can see it.
Try this:
fossil clone http://fossil-scm.org x.fossil
Success? You just used Fossil over HTTP. :)
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:
#!/bin/bash
OLDPID=`pgrep fossil`
if [ -n "$OLDPID" ]
then
echo "Killing old Fossil instance (PID $OLDPID) first..."
kill $OLDPID
typeset -i i=1
while kill -0 $OLDPID > /dev/null 2>&1 && [ $i -lt 30 ]
do
if [ $i -eq 1 ]
then
echo -n "Waiting for it to die..."
fi
sleep '0.1s'
i=i+1
done
echo
fi
fossil server -P 3691 --repolist /museum > /dev/null &
echo Fossil server running, PID $!.
This is a Bash script, so for Windows you'd have to run it under either Cygwin or WSL.
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.
That is, because we're serving a directory of Fossils in this case, you need to give the repository name to view a specific repository name. However, since we passed --repolist to "fossil server", if you visit the web root URL, you get a list of available repositories rather than an HTTP error.
Cloning worked fine. I could not push/sync or auto sync over authenticated http. So I could pull down code, and serve that code. But the only way to sync would have been push over ssh, or pull from the server - which doesn't really scale with 26+ clients.
[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.
]
> Cloning worked fine. I could not push/sync or auto sync over authenticated http.
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.
[Re-reading] your comment and it may be this is what I missed (although I'm fairly certain I tried both with "developer" and ["administrator" privs]):
> Make sure users have a Developer privilege, so that they can push the changes to the main repo.
And/or:
> 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?).
@e12e Try RhodeCode (https://rhodecode.com), we have quite a few educational users (e.g. Carnegie Mellon University) using RhodeCode in the way you described. RhodeCode also has secure authorization, user permission management and a web interface. One can even edit/commit directly from within a built-in web editor.
Is it Free/open source software and does it work off-line (on lan with sometimes intermittent Internet connection and/or can clients commit while offline, eg on a train journey with many tunnels[1], or on an airplane)?
[1] "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."
(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.