Fossil source version control


#1

Do you know Fossil?
I have a shared server and it’s not possible to install git, svn or cvs, anyway I must admit that I don’t like them.
Recently I came across Fossil and I post it here because probably some of you also have a shared server and need to use a source control system.
In 5 minutes Fossil was running as a CGI in the server. It’s just one file, that’s all, in fact Fossil is just one executable.
The repos are single files (SQLite databases). And it’s also very easy to running it locally (it’s not necessary to have a server to use it).
It’s very easy to use and it has its own internal web server for configuration, wiki/documentation, graphical history, tickets, bug-tracking, status…
And of course it runs on Win, Linux, Mac and OpenBSD.
At least for me it’s great.

http://www.fossil-scm.org


#2

doesn’t ssh access to files suffice as far as git “installation” goes?


#3

In your computer/s you can do anything, but the problem is that you can’t install git in a shared server to manage your repos.


#4

No, there is no ‘server model’ in git. A repo is a repo.

Fossil is sort of caught in between. It seems the goal was ‘integrated’ (source control + bug tracking + blogging (really)). It is quasi distributed, because that model has proven to be really solid on large scale projects, but runs back to a central server model for some things.

I’ve only given it a cursory look. But was underwhelmed. Then again, I’m jaded. I used RCS before VCS and have been putting scripts and wrappers around assorted ‘yacc’s’ (yet another cvs clone) for more than 20 years. I was primed for the Git model. I can work under source control on the plane ride to China, keep our resident mad scientist safely in his own branch and cherry pick… I’m happy.

It’s not that I don’t get the appeal of an integrated tool. I happen to really like Altium Designer, which we use here. A little bit of schematic capture, board layout, simulation, parts supply, MCAD, etc. But it has to be a balance that makes sense for you. To me, combining git with a ‘server by convention’ like GitHub, or other project systems, like Redmine, seems to make more sense than to have a weaker, less flexible source engine but integrated blogging. But mileage will vary.


#5

If only it wasn’t so monolithic, everyone could at least pick what they need in the binary, but it’s like a spaghetti plate in there… This was the biggest showstopper for me at the time I had a look at it a while ago.


#6

I’m migrating to git from svn, and I’m not looking back!

Follow me on github: http://github.com/vinniefalco

and Twitter for updates: http://twitter.com/#!/FalcoVinnie


#7

[quote=“jfitzpat”]
No, there is no ‘server model’ in git. A repo is a repo.

Fossil is sort of caught in between. It seems the goal was ‘integrated’ (source control + bug tracking + blogging (really)). It is quasi distributed, because that model has proven to be really solid on large scale projects, but runs back to a central server model for some things.

I’ve only given it a cursory look. But was underwhelmed. Then again, I’m jaded. I used RCS before VCS and have been putting scripts and wrappers around assorted ‘yacc’s’ (yet another cvs clone) for more than 20 years. I was primed for the Git model. I can work under source control on the plane ride to China, keep our resident mad scientist safely in his own branch and cherry pick… I’m happy.

It’s not that I don’t get the appeal of an integrated tool. I happen to really like Altium Designer, which we use here. A little bit of schematic capture, board layout, simulation, parts supply, MCAD, etc. But it has to be a balance that makes sense for you. To me, combining git with a ‘server by convention’ like GitHub, or other project systems, like Redmine, seems to make more sense than to have a weaker, less flexible source engine but integrated blogging. But mileage will vary.[/quote]

Over the years I’ve worked with git, svn, cvs and v. sourcesafe but for my personal projects (at home) Fossil is perfect, of course I do backups in external HDs and pendrives but I also wanted to keep copies of the repos in an external server and it’s possible (and very easy) to do it with Fossil. I really don’t use its bug tracking and blogging stuff.
I agree with Adrien, git do its job but it’s like an spaghetti.


#8

[quote=“Xavi”]
Over the years I’ve worked with git, svn, cvs and v. sourcesafe but for my personal projects (at home) Fossil is perfect, of course I do backups in external HDs and pendrives but I also wanted to keep copies of the repos in an external server and it’s possible (and very easy) to do it with Fossil. I really don’t use its bug tracking and blogging stuff.
I agree with Adrien, git do its job but it’s like an spaghetti.[/quote]

Well, adding an external server is basically adding a remote in git, git add remote name path… The server doesn’t have to be more than a file server.

I don’t see much reason in belaboring the git syntax, it was not even originally intended to be directly used. It was just plumbing for a source control system (that’s actually how we use it here, hardly anyone here ever types git commands directly).

To me, GIT and Fossil are very different tools, so it seems obvious that they will appeal to somewhat different audiences. The guy says it himself, Fossil is meant for small, flat, teams where everyone is concurrently working on a single branch. That is, Fossil intentionally keeps a very typical/traditional small team VCS model, then adds a little data distribution/replication and a lot of communication tools.

Git pretty much throws the old model away. Yes, you can mimic it, but things like branching, traditionally hard, are super easy and encouraged. It lends itself to some subtle (and not so subtle) changes in project/developer workflow. If, like us, you come to believe that the workflow changes help your productivity and bottom line, hard to remember syntax is no show stopper.

On the flip side, if your happy with a single branch and just need a way to blog stuff, cryptic command line syntax probably seems like murder. To each their own!