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

[Simon Geusebroek]

On Fri, 25 Mar 2005 11:00:06 -0600, John Arbash Meinel
<address@hidden> wrote:
> 
> Well, in general with any *source* control management system
> (cvs/svn/bk/etc) they are designed to handle source files, not the final
> products. Most people don't include their final executables or the
> compiled object files in the archive. (Some might do the executable, I
> doubt anyone does object files).
> 

Yes, I know I'm asking a lot to Arch, but since it's also a revision
control system, and that I have justly revisions to control, I'm sure
it would be clever enough to manage to do what I'm asking to it :).

You spoke to me about xdelta, but the problem is always the same: I'm
working with compressed files (I think that .deb files are compressed
like tar.bz files), and changing just one source file produce a
compressed archive *completely* different. I've tested it with tar.bz
files.

Subversion supports binary diffs between two revisions of a binary
file, in order to stock only the difference between them. But, of
course, when this binary file is a compressed archive, Subversion has
no other choice than to stock the complete new revision of the file,
BUT it stocks each new revision of the file only once.
For the same job (restricted to my job, of course this is not a
generality), an Arch repository needs twice more space than a
Subversion one.
Nevertheless I would prefer to use Arch instead of Subversion because
of its easier and better management of merging, but I have to solve
this size problem first (in the worst of the cases, I think I could
always use separate folders to stock .deb files).

I agree with what you say ("the first time the file exists, it will
only be entered 1 time, since the "previous" is Null"), this means
that the problem will only appear later, when I would have finished my
project for the university and would be gone away (I'm a student)… but
I would like to make something which is really usable, and I don't
think the people who will be using my system would be happy when they
see the size of the repository increase by 50 Go when, for example,
they upgrade to a new version of Debian (which will replace all the
.deb files at once…)…

Thank you very much of time that you devote me,
Simon Geusebroek.