Re: Space wasting

WOW.
This seems like its getting personal now.

Disk space is cheap right?

Or is this more of a bandwidth issue?

What kind of benefits would the end user see with or with out compression?
(Any ideas people?)

Thanks
Daniel Schulken

----- Original Message -----
From: "Alvin Thompson" <al@thompsonlogic.com>
To: "Brian Mathis" <bmathis@directedge.com>
Cc: <dev@subversion.tigris.org>; <users@subversion.tigris.org>
Sent: Monday, March 08, 2004 2:22 PM
Subject: Re: Space wasting

> would you care to enlighten us ignorant slobs as to why this is not a
> good idea instead of saying that it's 'simply ridiculous' and 'makes no
> sense at all'? and while i will defer to your supreme intelligence,
> would you please address and disprove the advantages propounded in the
> previous emails instead of just saying, 'there's absolutely no reason
> whatsoever to do it'? i realize i am just a foolish dolt who couldn't
> begin to comprehend your reasoning, but if you give some sort of
> explanation perhaps we of lesser minds can learn from your nuggets of
> wisdom, that we may not aggravate you further with senseless chatter?
>
> thank you for addressing my unworthy comments,
> alvin
>
>
> Brian Mathis wrote:
> > 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
> >>
> >>
> >>
> >
>
> --
> Alvin Thompson
>
> Navy: 34
> Army: 6
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.598 / Virus Database: 380 - Release Date: 2/28/2004
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org