Major changes in this release:
* Added sequential version numbering
* Added a optional configure script - the Makefile still works
for most systems.
* Improvements to the "annotate" algorithm: only search
primary ancestors and ignore branches.
* Update the "scrub" command to remove traces of login-groups
and subrepositories.
* Added the --type option to the "fossil tag find" command.
* In contexts where only a check-in makes sense, resolve
branch and tag names to checkins only, never events or other
artifacts.
* Improved display of file renames on a diff. A rebuild is
required to take full advantage of this change.
* Update the built-in SQLite to version 3.7.7.
New in release 2011-05-23 15:11:12:
This release merges in the windows internationalization patches.
Fossil should now work better on windows machines that use a
non-ASCII and non-UTF8 code page for the DOS box.
New in release 2011-05-12 14:56:52:
This release adds an enhanced configuration sync capability
which entails an irreversible schema change.
You _must_ run "fossil rebuild" on all of your repositories after
updating to this version of fossil.
Other changes in this release include:
* Refactor the "add", "rm", and "addremove" commands to
simplify the code and fix various problems.
* Added a "diff" hyperlink after each file in the "Show Files"
timeline view.
* The "fossil open" and "fossil co" commands always prompt
before overwriting preexisting files unless the --force
option is used.
* Enhanced the merge-conflict markup to show both recent
versions and the common-ancestor version.
* Change the definition of what it means to be a "leaf"
check-in, to be consistent and to work better for most
people.
* Commands that recursively decend through the file hierarchy
("fossil extra", "fossil clean", etc.) will now ignore
nested checkouts.
* Automatically delete the _FOSSIL_ file upon a failed "open".
* Improvements to the "annotate" feature.
* Other minor bug fixes.
- Support for git-fast-export format
- More efficient synchronisation mechanism
- "addremove", "bisect" and "stash" commands
- sqlite3 shell with some bindings to fossil logic like content_get
- undo cleans merge state
- Various improvements and bugfixes to other commands
manifests (resulting in much less metadata for large repositories), lots
of speed ups for the manifest parser, and smaller improvements like revert
dealing with merge records.
There are plenty of open-source version control systems available
on the internet these days. What makes Fossil worthy of attention?
1. Bug Tracking And Wiki - In addition to doing distributed
version control like Git and Mercurial, Fossil also supports
distributed bug tracking and distributed wiki all in a single
integrated package.
2. Web Interface - Fossil has a built-in and easy-to-use web
interface that simplifies project tracking and promotes situational
awareness. Simply type "fossil ui" from within any check-out
and Fossil automatically opens your web browser in a page that
gives detailed history and status information on that project.
3. Autosync - Fossil supports "autosync" mode which helps to
keep projects moving forward by reducing the amount of needless
forking and merging often associated distributed projects.
4. Self-Contained - Fossil is a single stand-alone executable
that contains everything needed to do configuration management.
Installation is trivial: simply download a precompiled binary
for Linux, Mac, or Windows and put it on your $PATH. Easy-to-compile
source code is available for users on other platforms. Fossil
sources are also mostly self-contained, requiring only the "zlib"
library and the standard C library to build.
5. Simple Networking - Fossil uses plain old HTTP (with proxy
support) for all network communications, meaning that it works
fine from behind restrictive firewalls. The protocol is bandwidth
efficient to the point that Fossil can be used comfortably over
a dial-up internet connection.
6. CGI Enabled - No server is required to use fossil. But a
server does make collaboration easier. Fossil supports three
different yet simple server configurations. The most popular is
a 2-line CGI script. This is the approach used by the self-hosting
fossil repositories.
7. Robust & Reliable - Fossil stores content in an SQLite database
so that transactions are atomic even if interrupted by a power
loss or system crash. Furthermore, automatic self-checks verify
that all aspects of the repository are consistent prior to each
commit. In over two years of operation, no work has ever been
lost after having been committed to a Fossil repository.
