This Page Is Obsolete

The original purpose of this page was to discuss potential future changes to Fossil for Fossil 2.0. However, when the Shattered attack against SHA1 appeared on 2017-02-23, the "Fossil 2.0" designation was used to indicate changes to Fossil to support SHA-3 hashes. See the discussion of Hash Policy for further discussion of the changes associated with Fossil 2.0.

For discussion of future Fossil plans, please see the Fossil-NG wiki page.

The original page content is retained for historical reference.

Status:

Fossil 2.0 is currently just an idea. No code has been written. (Update 2015-05-17: Some of the styling changes have been implemented on trunk for version 1.33 without being overly disruptive of legacy third-party skins.)

Core Principles:

100% repository compatible. Reuse existing repos (perhaps with "rebuild")
100% sync compatible. Push, pull, and clone with version 1.x repos.

Web Interface Enhancements:

Refactor to a small, sensible, well-defined and well-document set of CSS classes that are easy to configure.
OK to break existing skins.
Push toward being closer to RESTful
Strive for basic operation w/o javascript, though clearly javascript is allowed when necessary. (Javascript draws the timeline graph for example.) This principle does not change from 1.x.

Command-line Interface:

"fossil mv" and "fossil rm" actually rename and delete the underlying files.

Other Ideas:

The ability append remarks on a check-in. Appended remarks contain a timestamp and username.
The ability to attach a description to branch tag, indicating the intent or purpose of the branch.
Partial clones - the ability to clone only recent additions, ignoring older history.
Checkout from and commit to a remote repository (via HTTP/HTTPS) without having to clone. (The implementation would likely be to create a "partial clone" of just the one check-in that is being checked out.)
"Slices" - the ability to checkout, edit, and commit against a subdirectory of the complete source tree.
Advisory locks - The ability to "lock" a file on a central server to discourage other people from editing that file while you are working on it. Useful for binary files (ex: images or movies) that cannot be merged. Locks are advisory only and can be overridden with appropriate command-line options so that work can continue if (for example) one team member locks a file just before leaving on their three-week vacation.
Rework the VFILE table in the check-out database so that commits to repositories with a very large number of files (ex: net-bsd) is more efficient.
Optionally allow Fossil to read and write the Git object format (in addition to its own format) so that so that Fossil can clone/push/commit with standard Git implementations. A repository must decide at creation time whether it will be a Git-format repository or a Fossil-format repository and that can never be changed. Choosing the Git-format necessarily limits the things that Fossil can do, but with the trade-off of getting to participate in the pervasive Git community.

Implementation Strategy:

Make changes in a long-running branch (named "fossil-2.0"?) until ready to cut-over, then merge into trunk.
Keep two versions of Fossil (1.x and 2.0-alpha) both running on https://www.fossil-scm.org/ so that people can compare the changes to the web-interface easily.
Provide a place to download pre-compiled binaries of 2.0-alpha.

On 2015-02-06 02:10:35 UTC nobody (claiming to be sean) added:

Possibility of using a different hash, such as sha384 or sha512. Just because sha1 is fine doesn't mean it will always be fine. -- drh replies: Unable. This would be an incompatible file format change.
online file editing
alphabetization of lists
some style of pastebin with syntax highlighting, similar to tech notes or wiki
libressl support

On 2015-02-06 02:31:59 UTC nobody (claiming to be isxek) added:

Allow markdown use when writing tickets & ticket comments -- drh replies: Doesn't this already work in Fossil 1.30?
-- isxek replies: It does not. I'm using Fossil version [5260fbf632] 2015-02-05.

On 2015-02-24 22:12:00 UTC andygoth added:

Show cherrypick and backout merges in timeline and context.

Differentiate between normal, cherrypick, and backout merges by the shape of the arrowhead.

▲: Normal merge (or ◀ or ▶ as appropriate)
⭕: Cherrypick merge (resembles a cherry)
❌: Backout merge (signifies removal)

The merge lines may also be shown in different colors, e.g. green for cherrypick and red for backout.

Suggest allowing this feature to be configurable via theme. Also may be a user checkbox to show or hide cherrypick/backout merges.

On 2015-03-05 20:06:30 UTC andygoth added:

Require directory name argument to open command.

One thing that repeatedly surprised me when learning Fossil was that the open command opens the repository into the current working directory. This left me either confused at there being no apparent effect (except a hidden file called .fslckout, in the case of a new repository) or angry about Fossil making a big mess in my current directory (not easily undone because close doesn't delete).

I would have picked up on this behavior instantly had the open command required the directory name as an argument following the repository argument. The directory would be created if it doesn't already exist. For example:

fossil new repo.fossil
fossil open repo.fossil repo
cd repo

Opening into the current directory could still be done by supplying "." as the directory name.

fossil new repo.fossil
cd repo
fossil open ../repo.fossil .

This change would resemble the behavior of the fusefs command which requires a directory name argument.

This definitely hoses every script that calls open, but that's intentional since the goal is to force the (inexperienced) user to confirm that he really wants to open into the current directory. For current Fossil, a compromise form could be implemented which defaults the directory to ".", but Fossil 2.0 would remove the default.

On the mailing list, David Given suggested making the default directory name derive from the repository name. I suppose this means stripping a ".fossil" suffix, though there is no requirement that Fossil repository filenames follow any particular convention.

David also suggested allowing open's argument to be a URL, in which case it would clone the repository, make a directory for it, and open into the directory. It's not clear what the local repository filename would be, where to store it, and where to open it. A convention could be established to handle these things.

On 2015-03-07 19:12:15 UTC andygoth added:

Merge /dir and /tree.

It's unclear why these are separate. I advocate merging the code. Whichever one gets axed could be made to redirect to the other.

On 2015-05-15 05:49:01 UTC andygoth added:

Merge update and checkout. (Withdrawn)

The checkout command is very nearly the same as update. The only differences I can think of are that checkout doesn't trigger an autosync, plus it has -keep to change which checkout is selected without actually modifying files. (Also it has -force, but that's to work around a limitation of checkout not present in update.)

I actually use "checkout -force -keep" a bunch when synchronizing Fossil with other revision control systems, so this functionality must remain, even if it becomes "update -keep".

-- drh replies: Update merges any changes in the working directory over to the new version. Checkout does not. Checkout requires that there be no changes in the working directory, or else that the --force flag be used which overwrites all local changes.

If there is a well-defined difference between update and checkout, I am fine with them being separate. Prior to your explanation, they seemed so similar it was arbitrary that they be kept separate. Checkout selects exactly a particular checkout.

On 2016-05-15 07:05:24 UTC sdr added:

Interfaces to extend fossil

SQLite enjoys great extensibility through user defined functions and virtual tables (and of course VFS). There are people who would like this- or that-functionality implemented into fossil directly but there is resistance to the specific bit of functionality.

What about a way to register extensions with fossil? Such as a mailing list or forum or I have no idea what else?

Today, one is free to fork the project and maintain their fork. In the future it could be possible for people to maintain their functionality independently of fossil and just add it as part of the build process.