On Mon, Mar 08, 2004 at 01:40:43PM -0500, Alvin Thompson wrote:
> 1. so, by extension, *any* compressed file is a bad idea?
But there are some important questions to ask:
-) Does it make sense at all for svn to do it? (Complexity, portability)
-) If yes, aren't there other features that would be more critical?
-) If yes, who will do/fund the implementation?
> 2. the concept lives on in things like NTFS compressed file systems. but
> i guess MS will put any unreliable crap in their enterprise software
Well, if it's so important to you, why don't you just use the compression
support from the OS? As you've pointed out it's already there.
> --don't answer that! :) stock answers aside, you know what i mean.
> 3. when doublespace and stacker came out, we were using 50MHz CPUs.
> they're a bit faster now.
Correctly, and in some areas these 50MHz CPUs are still doing their work.
But the performance of the compression wouldn't be that big a problem
(as svn already in some cases compresses the data on the wire anyway),
it's more a question of:
-) reliability
-) portability
-) aren't there other things that are more important to do?
You haven't yet told us which library you would use. You just asserted that
such libraries are plentiful. Well, I'll assert for the time being that
such libraries are in fact quite rare.
So please tell me what compression library at least provides for the following
points:
-) lightweight,
-) fast,
-) portable (apr style, and apr runs on a number of funny platforms, e.g.
Novell servers, BeOS, OS/2, etc.)
-) support for inplace updates of files,
-) license compatible with svn,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 02:25:55 2004