--- Begin Message ---
|
Subject: |
Re: [Gnu-arch-users] GNU Arch 2.0 -- first source |
|
Date: |
Mon, 11 Jul 2005 09:19:50 -0700 |
On Mon, 2005-07-11 at 11:26 +0200, Matteo Settenvini wrote:
> I hope not to say a lot of bullshit ( :duck!: ),
Likewise :-)
> Thomas Lord ha scritto:
> > Crudely put, the main answer as to why revc is more space hungry is
> > that, at the scales of use cases of greatest interest, nobody is
> > (sanely) keeping score about this difference in space consumption.
> >
> > I'll say it differently: a modern revision control system can and
> > probably should gleefully consume local disk space at rates 10x..1000x
> > greater than, for example, CVS if, in return for doing so, user benefits
> > can be realized.
> This is usually fine for a centralized SCM like git. But how about
> normal users that have not-so-much disk space on their desktop, and want
> to sync to, say, kernel sources often? I don't want to go out to buy a
> new hard disk every once in a while to work on a project, even if
> storage nowadays doesn't cost much. This is also a problem of git, afaik.
But consider this comparison which applies to most current Arch users:
If you currently heavily use a revision library, Arch 2.0 will take
roughly the same (probably slightly less) storage and deliver
very similar functionality and performance.
So while we're talking about archives getting larger -- we're also
talking about Arch's on-disk data structures shrinking.
> revc, as tla, would be distributed, and you're likely to have a lot of
> local branches and revisions. I _liked_ small archives; I liked the way
> you could mirror them on a USB key, for example, or regularly backup
> them on cd, the whole of them.
We have been talking about the local on-disk format and you are
kind of changing the subject when you switch to backups.
As a straw-man, consider a program which reads a revc archive directory,
write a tar-file-like-stream describing its contents, inflating all
of the zipped "blobs" in the directory before writing them to the
stream. The inverse program which reads such a stream and constructs
the archive directory would also be trivial. Those streams,
passed through any decent compression algorithm, should be (at *least*)
competitive with tla 1.x's archive sizes.
-t
--- End Message ---