initial commitHEADmain

1 files changed, 81 insertions, 0 deletions

diff --git a/Readme.md b/Readme.md
new file mode 100644
index 0000000..ef81afd
--- /dev/null
+++ b/Readme.md
@@ -0,0 +1,81 @@
+# 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