Re: [Gnu-arch-users] Some issues

[Matthieu Moy]

Tom Lord <address@hidden> writes:

> You are talking about pennies per year, dude.

Err, have you ever administered a backup system? You should know that
in a corporate environment, the main cost of disk space is due to
backups, which _are_ actually expensive.

I don't think the "computers are not expansive, therefore I don't
optimize my software" match your philosophy. ;-)

There's something I don't understand. No one would reasonably propose
a revision control system storing full copies for source ASCII files
today. You could *off course* store a full copy for source files too.
You would have merging algorithms, usually more effective than just
storing the patch in the archive. That is clearly the *wrong*
solution. How is that different from binary files?

Your claim is that backup != revision control. I also don't understand
this. I have a powerpoint (:-/) presentation managed by arch. After a
set of modifications, I write a log file and commit. When I make a
mistake, I use "tla logs" to identify the revision I want to come back
to. Then, "tla get", ... If I have to branch, I can use "tla tag", ...
Off course, I can use only a subset of tla's feature, but why should I
drop tla ? My presentation is in a project with other source files,
why should I create a separate project not managed by revision
control?

My guess is that you never worked in an environment with people making
heavy use of binary files. Isn't it?

I know I could rather easily create a wrapper around diff+xdelta, but
you know as well as me that this would break the archive format
compatibility. Once again, my claim is not that tla should be modified
right now, but that 1) I would have liked to have it from the
beginning (too late ! ;-) 2) If the archive format ever change, it
should include a binary diff possibility.

There's a big difference between "We should have it, but it's not
reasonable to implement it now" and "We don't have it and we made the
right choice".

-- 
Matthieu