12

Newbie to Fossil (or any other version control system) here. Used a proprietary one earlier, but never set one up myself.

Currently, I am looking to set one up so that my friends and I can use it for a project.

I chose Fossil primarily because distributed seems to be the way to go, it seems lightweight and has an included bugtracker. But Git seems to be the favoured SCM for a lot of people. Is it worth the added complexity to favour Git+someBugTracker over Fossil? Are there any better alternatives? I will have to start from 0 on all.

Benoit
  • 76,634
  • 23
  • 210
  • 236
Samudra
  • 1,013
  • 1
  • 14
  • 21

1 Answers1

16

Just some thoughts, not organized.

If your friends are already used to gitting, Git is a good and robust distributed SCM, with great hosting services available, like Github or Gitorious.

Though, Git concepts are not easy to comprehend. Fossil has similar concepts, but is probably easier to start with (no staging area, no concept of index, reverting changes since last commit with revert not reset or checkout, etc). There are not a plethora of subcommands with plethoras of options, help is concise and clear. If you are afraid that you might be lost choose fossil. Of course, this also means that with fossil you can't do as many things as with git (no rebasing for example, at least not for the moment).

For fossil, there are few hosting online services available. It is as easy as it is with Git to setup a server to run Fossil.

Also, with Fossil, the history of a project is stored in a single file, thus I find it really easy to backup all projects: put all repositories in the same folder, and make a single rsync task. However this makes incremental backups totally useless.

While with git, working on two branches on the same projects in different folders would mean have two copies of the entire project history and branches in two distinct .git/objects directories that may be redundant and huge, with Fossil the default working scheme is have to have one single repository, and one or more working directories connected to it. Maybe if disk usage is important this will matter.

Warning, Fossil bug tracker (ticket system in the jargon) and wiki are quite rudimentary (though, they work well).

Community
  • 1
  • 1
Benoit
  • 76,634
  • 23
  • 210
  • 236
  • 5
    Git clones on the same partition will, by default, create hardlinks. So the only space you need is for the working tree – knittl Apr 05 '12 at 09:12
  • 1
    @Benoit, note that `rsync`-ing Fossil repos is a somewhat naive approach as it requires no write activity is done on that database file at the time of it being backed up. The only robust approach to do "online" backups is using `sqlite3 dump ...` and backing up dump files afterwards. And Git is not really that harder to back up: you just have to use Git itself to do this task. Moreover, if one needs a high-profile solution gitolite v3 implements master/slave replication on pushes. – kostix Jun 01 '12 at 10:03
  • @kostix: people like to do bitwise backups for several reasons. Although I don't see any legitimate reason to backup bitwise a fossil repository and not do an sqlite3 dump, some people will be reluctant to it. Also, fossil has replication, but won't replicate some data (typically the data that `fossil scrub` will remove). If that data is not needed to be backed up then just taking advantage of the replication should be sufficient to backup. – Benoit Jun 01 '12 at 15:09
  • 2
    You can use `git bundle` to create backups. Please refer to this question (and answer): http://stackoverflow.com/a/11163038/1047741 – shytikov Jul 11 '12 at 10:53
  • I haven't had a problem stashing between checkouts. What's a use case for multiple working directories? To me that sounds like more hassle... – bug May 23 '13 at 23:02
  • @Benoit: See [rdiff-backup](http://rdiff-backup.nongnu.org/) for a way around the incremental backup problem. – Warren Young Sep 13 '13 at 02:47
  • 1
    @bug: Two developers working on a single machine (e.g. a build server) who each want an independent checkout in their home directory. Checkins go to the `repo.fossil` file they have checked out from. Compare Git, where they have to push changes to each other even though they're on the same box. – Warren Young Sep 13 '13 at 02:51
  • @WarrenYoung The two developers don't necessarily have to push to each other: they can push to a third "main" repo on the disk, giving a centralized workflow. They'll still need to push and pull periodically. In fact, this happens in Fossil as well, but is implicitly done on each commit (SVN-style). – Dan Passaro Sep 24 '14 at 16:31