
Why I Use Fossil - twampss
http://sheddingbikes.com/posts/1276624594.html
======
gecko
While I love the _idea_ of Fossil, I think Zed downplays a lot of the problems
that it has in reality.

There's no real way to throw out branches easily, nor is there any rebasing.
Fossil doesn't track renames, so if you rename files in a branch, you'll need
to rename them again on mainline before the merge. Fossil doesn't have any
concept of patch management via email, which is fairly central to most OSS
projects I'm involved with. The bug tracker is not DAG-based, but rather last-
wins, which can result in some surprising outcomes. You have to log in to see
bug reports, which can be discouraging for users, and prevents your bugs from
being googleable. And so on.

I'm not saying that GitHub is perfect--hell, I make a competitor, based on
Mercurial no less, so I clearly don't think it is--but I think Fossil still
has enough fundamental flaws in it that I would be very hesitant to pick it up
for a new project. I'd rather deal with GitHub's proprietary system (of which
all data is accessible via its API [1]) than deal with Fossil's SCM quirks.
Zed clearly disagrees, and has projects where it's working for him, and the
SQLite project uses it, so it might work for you. But I would strongly
encourage caution. I'll personally be sticking to Mercurial and Git for now.

[1]: <http://develop.github.com/>

~~~
Goosey
"You can create branches by doing multiple commits off of the same base
version." It doesn't sound hard, but perhaps I am missing something?

~~~
gecko
I said throwing out branches you don't want is hard. You said creating
branches is easy. Those are both true.

------
pjhyett
If I may quickly address Zed's concerns about putting his code on GitHub:

1\. GitHub is a node on a distributed graph, you're still in full control of
your source and its history thanks to Git. Push your code to a dozen different
places, Git doesn't care and neither do we.

2\. We have soft disk space limits. If your OS project is massive, we're not
going to suddenly start charging you if you exceed that space. We want lots
and lots of open source projects on GitHub, we just don't want it to become
the place you host your music and porn, there are plenty of other services
that are happy to do that.

3\. GitHub's growth (thus revenue) skyrocketed during the recession, and it's
only getting better. We've rejected acquisition offers since the site was
launched, we care deeply about the service we've built.

~~~
nex3
I think the distribution issue is more about metadata than the code itself:
issues, wiki pages, and comments are still centralized on GitHub. With Fossil,
I gather, they're distributed among each clone.

~~~
pjhyett
We're slowly but surely moving towards having those things either become git-
backed or exportable. Wikis are first up and we're very close.

~~~
masklinn
Exportable is not the same thing as naturally distributed though. And git-
backed is nice, but with fossil it's fossil-baked as everything is tucked into
the exact same repository.

> Wikis are first up and we're very close.

Well yeah but as far as I understand, with Fossil it's done already, not just
close (and I'd say distributed bug trackers are closer than wikis if not done
already)

~~~
pjhyett
Integrating those systems directly into Fossil seems like a poor design
decision. Everyone has different requirements and it directs focus away from
the core responsibility of a VCS. Do one thing well and all that good stuff.

~~~
sophacles
People said that same sort of thing about RoR or Django too. "What?! You have
to do it the way they want? I prefer fooORM!", and so on. The point is not
that it is great at whatever, the point is it get stuff out of the way at
start time, and allow you to get to the meat of it quickly. Later on if the
project turns into something interesting, you can switch to redmine, or put a
real wiki behind it, and so on (but only as really needed).

~~~
nex3
That's an interesting point in light of Rails' recent movement towards more
modularity. It suggests that there may be room for a Fossil-like abstraction
over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.

~~~
sophacles
Honestly I've always wondered why redmine, trac, et al don't already build
their wiki on top of the vcs anyway, instead of using a separate database with
tracking. Such a step seems counter-productive.

~~~
nex3
I can see arguments both ways. Having the wiki separate means that the repo
doesn't get polluted with unrelated commits (especially important for SVN
which doesn't have branches), and it makes setup at least somewhat easier,
since an extra push-capable user doesn't need to be added.

~~~
bruceboughton
>> (especially important for SVN which doesn't have branches)

explain.

~~~
nex3
Subversion doesn't have a built-in notion of branches in the same way that
distributed systems do. Instead of being names for nodes in the DAG of
commits, branches in Subversion are usually handled by manually maintaining
separate versions of the same code in a branches/ subdirectory. In a
distributed system, you could keep a wiki or bug database on its own branch,
and commits to that branch wouldn't be visible if you only cared about the
main branch. In Subversion, those commits would be visible, because it's all
part of the same tree.

One caveat: Subversion's branch management may have changed since I last
looked (version 1.5 or so). However, systems like Trac and RedMine were
designed when branches worked as I described above, so it still serves to
explain their rejection of SCM-backed storage.

------
abstractbill
_I think you should know all the SCMs you can and be able to switch between
them._

Sometimes I feel like the modern programmer is expected to spend more time
learning to use multiple implementations of the same basic concept, than on
actual programming.

~~~
hello_moto
'tis true though. Imagine how many companies out there looking for specific
programming skills:

1) RoR NINJA!

2) jQuery EXPERTS!

3) JSF and/or Spring _and_ Struts2

4) C#, ASP.NET

5) All-things XML (XSLT, XSL-FO, XQuery, Xwhatever)

6) Specifically asking for DB2 or Oracle (not DBA, but for a typical developer
position)

Instead of the fundamental programming skills like fundamental Data Structure
and Algorithm, fundamental RDBMS, fundamental Software Engineering, etc.

On the other hand, I think Zed is just trying to be sarcastic to those who
said that "you must keep on learning new things, like myself, see... I'm
learning GIT" when it first came out but flat-out refused learning other
things at the same time.

~~~
erlanger
I took a job hiring a RoR ninja and jQuery expert as lead dev (for an alpha
app) and immediately rewrote it in Django and MooTools/Google Closure. You can
know the trendy stuff but still develop with solid software, provided you have
some latitude in technology decisions.

------
gcv
I looked at Fossil a few months ago. I basically liked it, but Fossil (1)
didn't do Git-style file rename detection, and (2) didn't have "git add
--patch" functionality. Has this changed? I can't really use an SCM without
those features anymore.

~~~
gecko
Forget rename _detection_ ; it doesn't do renames _period_. So if you rename a
file in one branch, you need to rename the file in the other branch BEFORE the
merge, or you'll simply end up with two different files with different names.

~~~
zedshaw
Sigh, bullshit. I do this every day and it's just fine. You must be referring
to some other concept of rename in some bizarrely complicated configuration
you've worked yourself into.

~~~
gecko
I am referring to this sequence:

    
    
        gozer:~$ fossil new zed.fsl
        project-id: e4549d02538b1b58cf28488f76fc7549dc11a752
        server-id:  0bb5e1159eef42ed514c6ec13d17ba05f21ecdea
        admin-user: benjamin (initial password is "068bda")
        gozer:~$ mkdir zed
        gozer:~$ cd zed
        gozer:~/zed$ fossil open ../zed.fsl 
        gozer:~/zed$ echo hello > hello.txt
        gozer:~/zed$ fossil commit -m "initial"
        fossil: nothing has changed
        gozer:~/zed$ fossil add hello.txt 
        ADDED  hello.txt
        gozer:~/zed$ fossil commit -m "initial"
        New_Version: 10c3840dc611fdc22888571560b908f36e647e59
        gozer:~/zed$ echo zed >> hello.txt 
        gozer:~/zed$ fossil commit -m "edited"
        New_Version: 10aa55193ddd374a75d37508cbc8a09466a05019
        gozer:~/zed$ fossil update 10c384
        UPDATE hello.txt
        gozer:~/zed$ mv hello.txt hello2.txt
        gozer:~/zed$ fossil mv hello.txt hello2.txt
        RENAME hello.txt hello2.txt
        gozer:~/zed$ fossil commit -f -m "renamed"
        New_Version: 3c3253cbd31cbc479c888fb8b1f38a8a46d8d4d6
        **** warning: a fork has occurred *****
        gozer:~/zed$ fossil merge 10aa55
        gozer:~/zed$ ls
        _FOSSIL_       hello2.txt     manifest       manifest.uuid
        gozer:~/zed$ cat hello2.txt 
        hello
    

And just to go the other direction, since some DVCSes behave differently if
their parents are in a different order:

    
    
        gozer:~/zed$ fossil update 10aa55
        ADD hello.txt
        REMOVE hello2.txt
        gozer:~/zed$ ls
        _FOSSIL_       hello.txt      manifest       manifest.uuid
        gozer:~/zed$ cat hello.txt 
        hello
        zed
        gozer:~/zed$ fossil merge 3c3253
        ADDED hello2.txt
        DELETE hello.txt
        gozer:~/zed$ cat hello2.txt 
        hello
    

Contrast this with Mercurial:

    
    
        gozer:~$ hg init zedhg
        gozer:~$ cd zedhg
        gozer:~/zedhg$ echo hello > hello.txt
        gozer:~/zedhg$ hg ci -Aminitial
        adding hello.txt
        gozer:~/zedhg$ echo zed >> hello.txt 
        gozer:~/zedhg$ hg ci -medited
        gozer:~/zedhg$ hg up 0
        1 files updated, 0 files merged, 0 files removed, 0 files unresolved
        gozer:~/zedhg$ hg mv hello.txt hello2.txt
        gozer:~/zedhg$ hg addremove -s100
        recording removal of hello.txt as rename to hello2.txt (100% similar)
        gozer:~/zedhg$ hg ci -mrenamed
        created new head
        gozer:~/zedhg$ hg merge
        merging hello2.txt and hell.txt to hello2.txt
        0 files updated, 1 files merged, 0 files removed, 0 files unresolved
        (branch merge, don't forget to commit)
        gozer:~/zedhg$ cat hello2.txt 
        hello
        zed
        

Git and Bazaar work similarly. This can come up very easily early in a product
cycle--doubly so if you have the misfortune of working on a Java project where
people are refactoring often.

------
bensummers
So, if you want to download and build it, here's the page:

<http://www.fossil-scm.org/index.html/doc/tip/www/build.wiki>

The prebuilt images are labelled as 'snapshots', and or you can "Select a
version of of fossil you want to download" to build from source with no
guidance on what version would be a good idea to use.

Maybe everything is stable? Who knows.

------
jf
Not to be confused with Plan 9's Fossil file system:
<http://en.wikipedia.org/wiki/Fossil_(file_system)>

------
mkramlich
he gave reasonable arguments, assuming one does always want all of those extra
features beyond VCS for each new project. for me, most of the projects i start
never need to go public, and of those that do, most don't need a full-blown
wiki or issue tracking system. README and TODO file are sufficient 99% of the
time, esp with no public collabs. so git and github still hit the sweetspot
for me in the default case.

~~~
FraaJad
Fossil actually fits this use case better than git or mercurial, because
fossil is just a 700 kb executable that you can take with you. No need to
install a package or hunt for cygwin versions.

and the whole repository is just a single file. Backing up your whole project
and the SCM is a matter of copying two files over.

Git is a swiss army knife for fossil's switch blade.

~~~
jfager
Fossil has a wiki, issue tracker, etc, all in a small little portable package
- it's far more deserving of the 'swiss army knife' label than git. Git's more
like an industrial lathe or something.

~~~
FraaJad
agreed! I was running low on industrial terminology atm.

------
Maro
We've been using git and github for a few months now, and it's not intuitive,
nor does it get out the way or offer to help to figure out what just happened.
I'm fairly sure that with time we'll get used to the common use-cases, but
right now I'm still backing up the 'src' dir before doing a 'git rebase'.

It looks like it's here to stay, so I'm hoping someone will make a set of
standard wrappers/GUI for making git bearable.

~~~
steveklabnik
Check out <http://progit.org>. It's awesome, and will teach you everything you
need to know about git.

------
sh1mmer
I think it's interesting that Zed considers Github/Bitbucket weaknesses. What
most open-source projects need more than self-hosting is contributors.

Portability is great but I'd rather have a project that I'm working with other
people.

------
Semiapies
I hadn't really heard of Fossil, so I went to read this post.

The one thing I really, _really_ didn't give a damn about as I went to read a
post like this was how everyone who doesn't like Fossil is merely a lazy,
ignorant goon.

Whatever. I know bloggers like to gin up pointless arguments for the sake of
controversy, but _I don't give a shit_ about that sort of vapidity.

------
experimentor
A sampling of the Fossil code. This is the source browser code.
[http://www.fossil-
scm.org/index.html/artifact?name=23a693054...](http://www.fossil-
scm.org/index.html/artifact?name=23a693054f1e70a9a63ca032ad5f66611cab0dfa)

C based webapps... lean, mean and blazing fast. And a little masochistic to
code.

------
trainwreckin
Ugh.

Zed, like drh miss the point yet again because they are closed minded
programmers and keep on forgetting that people who are not programmers may end
up using fossil as they wish to contribute a ticket or documentation to a
project running on fossil, but get reluctant dealing with the crappy UI or the
fact that they have to learn to do markup. It's also clear that drh really
isn't interested in anybody else but his needs.

Git has Junio Hamano who made it usable and practical to people who weren't
Linus. Who's this hero in Fossil? Well, it looks like the mailing list is
still waiting for them to arrive.

~~~
FraaJad
It is a program for programmers by a programmer. And Fossil is a VCS first and
and SCM second.

The beauty of git lies in what it does and that is managing code. The same is
true of fossil. DRH is known for making sqlite and in turn fossil rock solid,
and easy to program against. THAT is a far better feature and _interface_ than
some UI nitpicking you might throw at it.

------
torial
When I was evaluating Fossil about 1 year ago, compared to git and mercurial
-- one of the requirements for my company was that it support large files. All
of them supported large repositories, but easily ran into issues at about 10
MB for git and mercurial. Large file support for mercurial could be patched or
extended but not in an ideal fashion. Fossil was able to handle files up to
about 700 MBs in my tests before puking. I should add, those weren't binary
files -- but large XML files.

------
chappi42
Instead of a per-project-trac you could setup redmine which supports multiple
projects (tickets, wiki, forum, repo). Fossil looks interesting but I wouldn't
want to pass on git.

~~~
nuclear_eclipse
Or MantisBT, if you don't like managing Python/Rails processes. With plugins,
MantisBT can not only support multiple projects, but integrating multiple
repositories of multiple VCS types. I ran a single install at my last job with
many repos of three different source control types (Git, SVN, and an in-house
SCM built on SCCS).

