D 2017-11-18T20:57:19.653
L Fossil-NG
N text/x-markdown
P cf3950966893baf86daa7e1f2452476aeba8a3458e015945217172eeb3c1a4d1
U drh
W 4440
## Overview
This is a discussion format and record of ideas for the
"Fossil - Next Generation" or Fossil-NG. As this sentence is
being written (2017-11-18) there is no code in place for Fossil-NG.
## Goals
The first goal of Fossil-NG is to enhance and improve the Fossil user
experience based on lessons learned from 11 years using and maintaining
legacy Fossil. New capabilities include:
+ **Shallow Clones** - the ability to clone just the recent history
of a project
+ **Narrow Clones** - the ability to clone a subset of a project,
for example to clone only the files in the "src/" directory and
omit all of the files in the "test/" directory.
+ **Selective Sync** - the ability to push/pull/sync since branches.
In the 11 years since Fossil was created, Git has become the dominate
version control system. This is unfortunate, because of the various
version control systems available today, Git is the least user-friendly.
Nevertheless, there is no denying that any new version control system
(VCS) will need to deal effectively with the Git legacy. For this
reason, one important goal of Fossil-NG is to allow seamless integration
with legacy Git repositories.
The primary and most important purpose of Fossil is to support the
development of the [SQLite](https://sqlite.org/) project. Legacy
Fossil has succeeded fabulously in that respect. Any changes implemented
for Fossil-NG must respect that history. In particular, Fossil-NG
must be able to import the complete SQLite history intact, without
any changes to hash identifiers.
## VCS as File Container
By "file container" we mean a archive or bundling format such as
a tarball or ZIP Archive. One way to think about a VCS is as an
enhanced file container. Existing file containers allow one to create
a single snapshot of a project time. A VCS is the same except that
it allows one to store multiple snapshots.
Fossil-NG should have facilities to help to work as a simple file
container like tar and zip. One should be able to run commands like:
>
fossil new new-repo.fossil Makefile README.md src/
That command will create a file container named "new-repo.fossil" that
contains the files "Makefile", "README.md", and all files under src/.
This repository would be compact, and suitable for sending as an email
attachment, just like one would do with a tarball or ZIP archive.
The [SQLite Archiver](https://sqlite.org/sqlar/doc/trunk/README.md)
project shows how to build a file container using SQLite for storage.
Fossil-NG should include the capabilities of SQLite Archiver, though
the underlying file format will doubtless be more advanced so that
it can also support block-chain versioning.
Current Fossil provides web-page links and command-line operations for
generating a ZIP archive or tarball for a particular check-in.
Fossil-NG should continue to have that capability, but should also
be able to generate a single-checkin repository that serves as a
file container.
## Support For Multiple VCS Formats
Fossil-NG should provide the ability to store artifacts in various
formats:
1. Git
2. Mercurial
3. Legacy Fossil
4. Fossil-NG
A repository that contains only Git-formatted artifacts should have the
capability to interoperate seamlessly with Git repositories. This allows,
for example, a Fossil-NG user to clone and use a repository out of GitHub
while continuing to use the superior Fossil user interface. It also
allows a Fossil server to answer clone/push/pull requests from legacy
Git clients. The same symmetry applies to Mercurial and legacy Fossil.
Thus, by using a single Fossil-NG client and user interface, a developer
can interact with legacy repositories in a variety of formats, without
having to learn the idiosyncrasies of multiple VCSes.
Fossil-NG itself will be able to operate on repositories that hold a
mixture of artifacts in various formats. Legacy Git, Hg, and Fossil
clients, however will only be able to interoperate with Fossil-NG
repositories that hosts all artifacts in the one format the the client
understands.
Converting artifacts from one format to another is an expensive computation -
too expensive to do on-the-fly. However, it is conceivable that Fossil-NG
could be used to convert repositories between Git/Hg/Fossil formats as
an off-line operation.
Z 6ec4ca575511efa9cc9374c8363f9ed3