[ostree/wip/packfile-rebase2: 3/11] libostree: Add README.md
- From: Colin Walters <walters src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [ostree/wip/packfile-rebase2: 3/11] libostree: Add README.md
- Date: Thu, 22 Mar 2012 03:14:09 +0000 (UTC)
commit 10f952cf8c5e80c891a29baaed2c9e6f32100d62
Author: Colin Walters <walters verbum org>
Date: Fri Mar 16 17:50:05 2012 -0400
libostree: Add README.md
src/libostree/README.md | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
---
diff --git a/src/libostree/README.md b/src/libostree/README.md
new file mode 100644
index 0000000..04d1462
--- /dev/null
+++ b/src/libostree/README.md
@@ -0,0 +1,30 @@
+Repository design
+-----------------
+
+At the heart of OSTree is the repository. It's very similar to git,
+with the idea of content-addressed storage. However, OSTree is
+designed to store operating system binaries, not source code. There
+are several consequences to this. The key difference as compared to
+git is that the OSTree definition of "content" includes key Unix
+metadata such as owner uid/gid, as well as all extended attributes.
+
+Essentially OSTree is designed so that if two files have the same
+OSTree checksum, it's safe to replace them with a hard link. This
+fundamental design means that an OSTree repository imposes negligible
+overhead. In contrast, a git repository stores copies of
+zlib-compressed data.
+
+Key differences versus git
+----------------------------
+
+ * As mentioned above, extended attributes and owner uid/gid are versioned
+ * SHA256 instead of SHA1
+ * Support for empty directories
+
+Binary files
+------------
+
+While this is still in planning, I plan to heavily optimize OSTree for
+versioning ELF operating systems. In industry jargon, this would be
+"content-aware storage".
+
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]