gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Free space wasting when handling binary files


From: Adrian Irving-Beer
Subject: Re: [Gnu-arch-users] Free space wasting when handling binary files
Date: Fri, 25 Mar 2005 15:19:59 -0500
User-agent: Mutt/1.5.6+20040907i

On Fri, Mar 25, 2005 at 08:54:44PM +0100, Simon Geusebroek wrote:
> Because I'm not using Arch for software development: I have to
> version control live-CDs, that is to say complete workspaces.
[...]
> and it is much practical to simply manage .deb files and a set of
> scripts which would build .iso images on demand…

Personally, if I were faced with this, I'd make an arch project with
only the scripts to do the job, and then I'd just have trees of
packages they could rsync from.

The trees themselves (on the server side) can be 'rsnapshot' style; that
is, every new tree is a hardlink of the previous tree (almost zero
space), with the packages that changed rsync'ed in over top.

So it's actually a bit like an arch revision library -- if a file
changes, there's a whole new copy, and if it doesn't, the old file is
still there and it takes almost no space at all.

Large binary files, particularly compressed ones with no real relation
to each other, *will* work in arch, but it's not the primary nor the
optimised case.  Every patch in arch must be reversable, and that cannot
happen if only one version of the file is stored.

You really won't get anything better without a smart server that can
specifically serve up a particular version of each file, IMO.  arch's
dumb-server design is nice for source control, but not too good at all
for massive binary control.

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]