— part of check-in
on branch trunk
— Remove control characters from rse-notes.txt.
From: "Ralf S. Engelschall"
Date: October 18, 2008 1:40:53 PM EDT
Subject: Some Fossil Feedback
I've today looked at your Fossil project (latest version from your
repository). That's a _really_ interesting and very promising DVCS.
While I looked around and tested it, I stumbled over some issues I want
to share with you:
o No tarball
You currently still do not provide any tarballs of the Fossil sources.
Sure, you are still hacking wild on the code and one can on-the-fly
fetch a ZIP archive, but that's a manual process. For packagers (like
me in the OpenPKG project) this is very nasty and just means that
Fossil will usually still not be packaged. As a result it will be not
spreaded as much as possible and this way you still do not get as much
as possible feedback. Hence, I recommend that you let daily snapshot
tarballs (or ZIP files) be rolled. This would be great.
you describe the concepts and you clearly name the artifact ID a
"UUID" and even say that this is a "Universally Unique Identifier".
Unfortunately, a UUID is a 128-bit entity standardized by the ISO
(under ISO/IEC 11578:1996) and IETF (under RFC-4122) and hence it is
*VERY MUCH* confusing and unclean that your 160-bit SHA1-based ID is
called "UUID" in Fossil.
I *STRONGLY* recommend you to either use real UUIDs (128-bit
entities, where a UUID of version 5 even is SHA1-based!) or you name
your 160-bit SHA1 entities differently (perhaps AID for "Artifact
o "fossil cgi <script>"
Currently we have only "fossil cgi <script>" where <script> contains
"repository: <file>". This is a neat idea and should be kept. But
this way one cannot easily host multiple repositories over this
CGI interface without creating such a script for every individual
Perhaps a "fossil cgi --repository <file>" would help here, as this
way one can use a generic CGI script which first figures out the
name <name> of the individual project and then runs "fossil cgi
--repository /path/to/repositories/<name>.db". But perhaps I'm just
overlooking something and this is already possible...
o "fossil db <operation>"
In Monotone DVCS we have a "mtn db" command for the low-level SQLite
database manipulations. For instance a "mtn --db=<monotone-repository>
db dump" is more or less equal to a "sqlite3 <monotone-repository>
.dump". A "mtn --db=<monotone-repository> db exec '<SQL>'" is equal
"echo '<SQL>' | sqlite3 <monotone-repository>", etc. The point is
that the DVCS user usually has no SQLite CLI at hand but as the DVCS
already contains more or less the complete SQLite it is very useful to
also include the SQLite CLI functionality and wire it into the DVCS
CLI via a "db" command.
o "fossil version"
Mostly all VCS I know if either support a command "version" or a
command-line option "--version" or most of the time even both. Please
output the "This is fossil version [9e80dc66cf] 2008-10-18 13:03:36"
there (at least additionally) instead of at the end of "fossil help".
o "--port" vs. "-port"
In the "fossil help server" there is "--port" while under
is "-port". I personally like GNU-long-style options "--xxxx" more
than the CC-style options "-xxx". But anyway, independent which one is
correct (well, perhaps both even work) only one should be documented
to avoid confusion.
o User creation on the CLI
There is "fossil user new ?USERNAME?" which interactively prompts
for the capabilities and the password -- even from the TTY and not
from STDIN. One needs "fossil user new ?USERNAME? ?CAPABILITIES?
?PASSWORD?" to be able to create a repository in batch without having
to hack the user into the "user" table via the SQLite CLI. Similar:
the "fossil user password USERNAME" should be actually "fossil user
password USERNAME ?PASSWORD?", please.
o "-R <repository"
There is the "-R" option for specifiying the repository. But it is
a sub-command option and not a global option. And on "fossil ui" or
"fossil server" it even is an argument and not an option. This is
confusing. Every time one has to figure out how to set the repository
on the CLI. Monotone simply uses a *global* option "--db" and that's
it. So, I recommend that Fossil also uses a single global option
"--repository"/"-R" instead of a command-specific option. Sure, not
all commands might require a repository, but IMHO it is better to
ignore the global option there than having to figure out every time
how the repository has to be specified.
o Setup pages
When hitting "Apply changes" on any setup page, one keeps staying on
this page. Sure, that's what an "apply" button usually is about. But
I at least would have liked to see a button (either instead of the
"apply changes" or at least in addition) which applies the changes and
goes back to the setup main page (from where one usually come).
Very nice idea to use another SQLite database for the _FOSSIL_
control file. BUT: Why "_FOSSIL_"? CVS's "CVS" directory was ugly for
decades. Today we have ".svn", ".git", ".hg" and "_MTN"/".mtn" to get
rid of those ugly control files or directories of the DVCS! Sure,
dot-files are disliked by Windows people. But that's no problem, one
can accept "_XXX" in addition to ".XXX" easily, of course.
So, I really would like to see the file "_FOSSIL_" to be renamed
to ".fossil" under Unix and "_fossil" under Windows or (if the
upper-case is important to you) ".FOSSIL" and "_FOSSIL". But to see
an ugly "_FOSSIL_" at the top of every source tree is really rather
boring for Unix people!
o "fossil open", "fossil checkout", "fossil update".
I'm personally confused that "fossil open" is what "checkout" does in
other DVCS and that "checkout" is just a variant of "update". Hmmm...
for me it looks at least one should be eleminated to reduce confusion.
The difference between checkout and update could become an option of
a single option. And the remaining to perhaps better should be either
"open" + "update" or "checkout" + "update". Well, perhaps I'm still
not understanding Fossil enough. But I can only tell that I got rather
o "fossil commit"
There is "fossil commit" but no short-hand "fossil ci". But there
is "fossil status" and even just "fossil st" which clearly shows
that Fossil allows abbreviations or at least prefix-matching on the
commands. Sure, "ci" is not a prefix of "commit" but mostly all VCS
support the good old RCS/CVS "ci" and similar aliases. So I recommend
that Fossil does not only alias matching, but also provides aliases:
"ci" for "commit", "co" for "checkout", "log" for "timeline", etc.
Sorry, having to type the long "fossil commit" every time is too long
for us Unix hackers ;-)
Additionally, Fossil seems to use GnuPG when installed and --nosign is
not specified. Hmm... two questions arise here for me: 1. should the
use of a cryptographically strong signature really be just _optional_
(Monotone for instance RSA signs every commit) and 2. is GnuPG here
really the right tool (Monotone does a plain RSA signing and is even
able to leverage a running SSH agent for the operation -- something
which is very cool both under Unix with "ssh-agent" and under Windows
with "pagent"). OTOH, GnuPG 2.x supports a gpg-agent, so this might be
no longer a big issue. But Fossil should document this a little bit
futher: how to create the necessary GnuPG key, how to setup gpg-agent,
o "fossil diff"
There is "Usage: fossil diff|gdiff ?-i? ?-r REVISION? FILE...". Two
questions arise: Why do I have to specify a "FILE"? I would expect
that a simple "fossil diff" recursively shows a "diff" of all changed
files in the source tree. Additionally, how does one do a diff between
two particular revisions (one seems to be not able to specifiy "-r"
o "manifest" / "manifest.uuid"
Above I was already bothered by the _FOSSIL_ file, but now that I
played with Fossil I see that "manifest" and "manifest.uuid" files
showed up in my source tree. Why is this not implicitly in the
database and instead externally represented in the source tree.
Hmmm... then I recommend that you use a .fossil *DIRECTORY*, place
the control file into .fossil/control (or whatever) and the manifest
stuff into .fossil/manifest and .fossil/manifest.uuid. But please do
not clutter the top-level of the source three with control data of the
o "fossil mv"
There is "fossil add" and "fossil rm", but no "fossil mv". Hopefully
this doesn't mean a file move is an "add" and a "remove" bundle, as
this way Fossil would have trouble to know that the file was renamed
and hence the full history tracking of a file seems to be broken.
o "fossil changes" vs. "fossil status"
Finally, I got confused by the "fossil changes" and "fossil status"
commands. "fossil status" seems to be a super-set of "fossil changes".
Looks a little bit less orthogonal than necessary. I would remove
"fossil changes" or at least do not show the file details on "fossil
Ralf S. Engelschall