## 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:

  *  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
     so that so that Fossil can 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
     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.  <i>-- replies:
Unable. This would be an incompatible file format change.</i>
* 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 <i>-- replies:
Doesn't this already work in Fossil 1.30?</i>
<br /><em>-- isxek replies: It does not. I'm using Fossil version [5260fbf632] 2015-02-05.</em>


------
*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

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>-- 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.</i>

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".