# sv

sv is a source versioning tool.

## Why sv ?

Well git exists for almost 20 years now, and is now the de-facto
standard. Its design is sound, it works pretty well and is definitely
better than the previous generation of tools (cvs, subversion,
clearcase, etc.).

But to me, git is too large and complex in its format, usage, and
overall code. According to a [security audit on git], git has a
quarter of millions lines of code, C, Bash and Perl. This is not a
complaint.  Git is extremely useful, and covers succesfully an
incredibly large scope of uses.  But for my own simple usage, I
feel it is too large and complex, still too opaque.

I would prefer the storage of versions to be transparent: previous
versions stored directly as trees, not opaque archives. I would
prefer to see real version names instead of cryptographic sums,
which are useful but not in the face of users.

Patches are already in the right format: unified diff.

Storing the full history in place (under .git) is also very nice.

I think that it should be possible to create a small and minimalist
tool in a shell layer just on top of existing standard (POSIX) unix
commands to manipulate text files to implement all basic requirements
for a versioning system.

## Wanted features and constraints

- transactional: changes should be atomic, replayable, reversible,
  work correctly in distributed mode (client-server architecture).

- centralized: having one source of truth. Do not forbid replicas.

- transparent: every thing stored as pure text files, no tools
  needed to extract, browse, understand files. Use the file system
  as database.  This is the condition to remain usable over decades
  and decades, even after long unused periods.

- simple and minimal, thus secure. Unix philosophy: compose simple
  tools which are fast and proven, glued by shell script. Ideally,
  only one shell script necessary, no other dependencies than core
  system such as busybox+ssh or openBSD.

- fully self contained: each repo or clone contains the whole
  history, but also the minimal tooling to operate (at least the
  sv script itself).

- robust in presence of incomplete or degraded tooling: for example,
  still operate if no checksuming available (give up warranty on
  integrity).

- robust in presence of missing versions or patches.

- comply to standards whenever applicable: dates, mbox format, posix
  tools (sh, diff, patch).

## Low priority features and constraints

- performance: if you think it should be faster or more efficient,
  use git instead.

- support of binary or large files. Outside scope. Small binary
  files can be uuencoded.

- support of symbolic links.

- support of file modes and permissions.

## Todo

- branch command: create a named branch from a version
- checkout command


[security audit on git]: https://www.x41-dsec.de/static/reports/X41-OSTIF-Gitlab-Git-Security-Audit-20230117-public.pdf