Fossil

Fossil 2.0
Login

Status:

Core Principles:

Web Interface Enhancements:

Command-line Interface:

Other Ideas:

Implementation Strategy:


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


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


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.

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.