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
--
Alvin Thompson
Navy: 34
Army: 6
---------------------------------------------------------------------
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:26:08 2004