On Fri, 25 Mar 2005 11:00:06 -0600, John Arbash Meinel <[EMAIL PROTECTED]> 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. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/