[Nix-dev] An interview to the fossil creator about fossil

[Michael Raskin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/08/2010 10:58 AM, Lluís Batlle i Rossell wrote:

- -- Summary of things I found interesting in the original mail --

Unique for Fossil:
- -> Optionally inherited generic commit properties (suboptimal querying
abilities, though)
- -> Optional autosync when connection is available.

Of non-unique points, "easier than Git" was mentioned twice.

Negative point: not obvious how to migrate to/from it.

Also, "Perl is a hell to cross-build, so let's avoid Git [and ikiwiki?]"
seems to be a new angle in the discussion.

- -- End of summary --

Note that I am in favour of Monotone, so many things in fossil look like
misguided clone of Monotone to me.

>>> On IRC #nixos we talked about fossil, so here you have an interview to its
>>> creator about it:
>>> http://bsdtalk.blogspot.com/2010/07/bsdtalk194-fossil-scm-with-d-richard.html
>>>
>>> He explains it comparing to other systems.
>>
>> The fun thing is that he says very little about pure SCM side comparison
>> (he talks more about a full-package vs SCM); and doesn't even mention
>> standalone wiki-over-DVCS/bug-tracking-over-DVCS solutions.
> 
> Although Fossil comes with bug-tracking and wiki, when I sent the link it was
> not what I had in mind as relevant in the talk.

Well, I mentioned what he seems to paint as relevant, looking at
timeshare devoted to it.

> Some of the points I like of Fossil, then:
> - It does not allow the kind of git history rewriting. Thus, I favour the use of
>   more branches with full history keeping instead of "rebase -i; push".

The same goes for mercurial and monotone. Of course, doing an iterated
plucking/cherry-picking and not pushing the old branch allows to emulate
this workflow, although they may run somewhat slower.

> - It's written in C and the author means it to work everywhere without being a
>   pain to install. From everywhere it may mean complicated platforms as Windows,
>   Mac OS X or linux on the Ben Nanonote. For me it's a big plus.

Well, if you can install Boost, installing Monotone is simple. For
Windows, MacOS X and Solaris there are official binary packages (there
is a binary tarball for Linux, too, but why bother)

Also, I cannot tell that installing Python is a big undertaking. Bazaar
claims a goal of being easy (not just "par for the course") to install
on all platforms and seem to achieve that. Neither do I remember
troubles with Mercurial installation.

Maybe even Git-on-Windows got easier to install with years.

> - The bug tracking and the wiki do not clutter the commit log. They are meant to
>   be branch-agnostic, and be for the whole repository regardless of the branch,
>   in opposite (in advantage) to other in-VCS solutions.

If you consider it an advantage, you can trivially put them in a
separate branch or repository. Some of the solutions offer you this
choice...

> - It looks like using few disk space and few bandwidth - for me this looks as
>   scaling well.

There is also a thing like "interface scaling" - whether what it does
for branches is comfortable when we try to actually use it in a big project.

> - Autosync mode allows some kind of centralized VCS behaviour, as far as the
>   connection to 'the server' can be established.

Now that is something worth noting. At least among WebUI solutions
(otherwise hooks or script wrappers solve everything)

> - I find it far easier to use than git

Well, not unique here.

> - Allows per commit propagated and not propagated tags and properties, although
>   it still does not offer a complex search and usage of them. For this monotone
>   clearly wins.

Well, monotone seems to lack propagated properties. At least by default.
Probably a few hooks will solve this, of course.

> - The Web UI gives an additional improvement over the console interface for
>   free, at every installation of fossil, without the need of additional
>   software.

I'd say that installing viewMTN or whatever is too simple to note. We
can make an integrated package, I don't know. It's not like we are
afraid of version conflicts with every new package.

> - I find it far easier to handle than git (and it's not that I don't use git)

Duplicate

> What I don't like much:
> - I have not understood the history keeping of the UI 'Edit check-in' features,
>   that allow a rewriting of the comment, and some other things.
> - Some operations can be done only through the web ui, which is both thought as
>   a normal UI for local usage, and as a public web server. Then, tickets can
>   only be managed through the web ui. "fossil ui" starts the server and tells
>   firefox to open that page, in that single command. I'd like a full featured
>   command line.

Maybe it will come with time.

> - I still have to see migration scripts other than CVS to Fossil.

I guess there are none

> Urkud talked about the linking between different projects, but I don't know what
> was he thinking about. Urkud, can you explain what you had in mind? Do you mean
> the git ability to pull from a repository *only* commits for a single branch,
> instead of pulling all?

No, the idea seemed to be about bug tracking.

> Related to 'git', I've found this days how difficult it is to cross-build perl,
> and I feel it difficult for me to accept more things perl-based, having other
> not-worse solutions around. :) 

Try building Python and Boost (so Bzr, Mercurial and Monotone
cross-building efforts can be estimated)..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMXnhbAAoJEE6tnN0aWvw3mRsH/1LtGscqbEc+KPsgxiR8kZLp
0LpsVTIiTnmQwka5NSi2gMrbP6GJ6+YbKaJN9Hq8l/3tNzSsFjE1Xa1M9Es//+eQ
vF5AJQI+46WgBhmjkAP5tVoSuHySlSrTFkxGLd8gIpbRh0pauF0aEKNjc5tNH6FG
oyMav7sf6oVAd8YN4P7bqQ1AaTmfDcDRsSvH8s29kVrBwZ4hPugjdOV+uo5Uk6Al
///jz1+A1N7kCgRquXiKv9pbdlUpm7cWcHtlA3bnsRd+pRm/HZ9Z7zLQmkECHja4
sVg5MQp03+pZJe1vfl5E9RQxQ79GDWSU07lVSinMw7/GrSF48ilx5ku4QBqERj4=
=T5nw
-----END PGP SIGNATURE-----