You guys are putting way too much into this. Storing everything
compressed is simply ridiculous. There's absolutely no reason
whatsoever to do it, and many, many reasons NOT to do it. On top of
that, it makes no sense at all.
If you really want this, submit an Issue Tracker request for it and hope
it gets done one day. Otherwise, please stop this ridiculous argument.
Alvin Thompson wrote:
> Andreas Kostyrka wrote:
>
>> -) Handling of files >2GB.
>
>
> so pick a format that handles files over 2GB
>
>> -) Not optimized for updates -> slow updates.
>
>
> first, as i mentioned before virtually any processor still in use can
> keep up with a light compression algorithm. you don't need the densest
> possible compression algorithm for this application.
>
> second, it's not everyday that you need to compress/decompress the
> entire thing. most compression schemes today are smart about which
> 'hunks' it needs to play with.
>
>> -) Not as portable as apr/svn -> new portability problems.
>
>
> how does this affect portability? explain.
>
>> So basically we need a new format (.zip files don't cut the 2GB
>> limit), and
>> new tools to examine the working copy, new tools for everything.
>> For little gain. And these are real problems, as you might have
>> noticed svn
>> is quite "high-quality" source code. :)
>
>
> as i said, there are about a billion compression libraries out there.
> and as i said, most would *not* require a substantial rewrite of code.
> the only difference would mostly be how it gets its file streams.
>
>> And makes it slower, because it has to compress the stuff. Doesn't sound
>> like a problem, but it is, at least when you have collections of big
>> binary
>> files that compress badly.
>
>
> see above and the previous email.
>
>>> * it helps the tortoise SVN speed issues.
>>
>>
>> How would doing more work make a client faster?
>
>
> please reread that thread. basically, since it is essentially a branch
> of Tortoise CVS, it uses much of the same code. since cvs doesn't have
> to worry about pristine copies or (usually) large numbers of files in
> the .cvs directory, it uses a simple recursive algorithm when scanning
> for files for that icon overlay feature. that slows Tortoise SVN down
> because it doesn't ignore the .svn directories. while they probably
> will/should fix this, it is yet another difference between the two
> which makes the code harder to maintain. and once again, wouldn't it
> make more sense to implement this than to require that every other
> program on the planet be SVN aware?
>
>>> basically, it fixes all apps (including those not mentioned above)
>>> which have to recursively scan folders to do their job. you don't
>>> think this is a more elegant solution than requiring every other
>>> program on the planet to be 'SVN aware'?
>>
>>
>> Well, I'm quite sure that management areas inside a working copy aren't
>> svn speciality -> so tools usually are capable to deal with that
>> situation :)
>
>
> what? 'management areas inside a working copy aren't svn speciality'?
> why on earth wouldn't they be? how does that answer that question? i
> assume you don't have an answer so you just randomly strung together
> some words. :P
>
>> And as to the ".NET/ant" Wheenies, they've got the source code, so
>> they can
>> solve their problems themselves? Or did I miss somewhere the
>> declaration that
>> working around bugs in certain MS IDEs is a high priority item for svn?
>
>
> i will repeat this yet again: wouldn't it make more sense to implement
> this than to require that every other program on the planet be SVN aware?
>
>> Andreas
>
>
--
Brian Mathis
http://directedge.com/b/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 8 19:46:43 2004