[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: arch lkml
From: |
Miles Bader |
Subject: |
[Gnu-arch-users] Re: arch lkml |
Date: |
11 Dec 2003 10:31:02 +0900 |
address@hidden (Eric W. Biederman) writes:
> > One thing _is_ clear: the current representation is a _huge_ win if
> > something goes wrong, because it doesn't use a big-binary-blob (or multiple
> > smaller-binary-blobs) every storage, everything is in clear common formats.
>
> Hmm. gzip tar files are binary blobs, just in a common format.
Perhaps my point wasn't clear.
Arch's (current) storage format:
(1) Uses the filesystem in a natural way, with each changeset (a fairly
small unit) in a separate file, divided into directories organized
along branches/categories/etc.
(2) Puts changesets into .tar.gz files, with a completely straight-
forward and obvious organization (even to someone that doesn't know
anything about arch).
(3) Essentially never, ever, touches old files, it just creates new ones.
Some of the advantages of this representation are:
* You can _easily_ (without installing _any_ new tools, and _without_
documentation) look over the whole archive, see how it's organized
and get all your data out. If all the executables, sources,
documentation, and hackers of all arch implementations ever written
suddenly exploded, you could _still_ get your data, and do something
useful with it. A good hacker with superficial knowledge of arch
could probably even reverse-engineer a new arch implementation just
from looking at an archive.
* Because of (3), a bug in arch is unlikely to ever trash your archive;
a bug in the filesystem code could do it, but that's _much_ less
likely [and of course will affect any other representation too].
* As with CVS, if you _really_ want to, you can go in and _edit_
arch archives, to do something arch doesn't support, and you can do
this with normal unix shell scripts and tools. Clearly this is not
a very safe thing to do, but in the real world, sometimes this sort
of thing is necessary, and with arch, it's at least a little bit
less dangerous.
The `binary blob' I was contrasting with is where the repository is
stored in a single big file, with a non-standard binary-format. This
sort of representation is _much_ scarier.
-Miles
--
If you can't beat them, arrange to have them beaten. [George Carlin]
- Re: [Gnu-arch-users] arch lkml, (continued)
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Eric W. Biederman, 2003/12/12
- Re: [Gnu-arch-users] arch lkml, Christopher Dale, 2003/12/12
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/12
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/12
- Re: [Gnu-arch-users] arch lkml, Eric W. Biederman, 2003/12/13
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/13
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/13
- [Gnu-arch-users] Considering Semantics with a simple but stupid file archive format., Eric W. Biederman, 2003/12/13
- [Gnu-arch-users] Re: arch lkml,
Miles Bader <=
- Re: [Gnu-arch-users] arch lkml, Aaron Bentley, 2003/12/11
Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Mark A. Flacy, 2003/12/10
- Re: [Gnu-arch-users] arch lkml, Roman Zippel, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Tom Lord, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Bruce Stephens, 2003/12/11
- Re: [Gnu-arch-users] arch lkml, Robert Collins, 2003/12/11