Re: Space wasting

that's exactly *my* point. you would have to rewrite/inspect the code of
everything out there to ensure it works properly with SVN. it makes more
sense (to me, anyway) to make sure that SVN doesn't have that problem in
the first place.

-alvin

Jeff Bowden wrote:
> javac `find . -name .svn -prune -o -name "*.java"`
>
> Alvin Thompson wrote:
>
>> the problem is neither disk space nor bandwidth. the problem (in a
>> nutshell) is that many tools/scripts recursively scan directories
>> looking for files to do stuff to ('grep/find' operations, build
>> scripts, etc) and since SVN keeps pristine copies of the files in its
>> .svn directory, all tools/scripts must know to ignore them or be
>> confused and do bad things. for example, a command of this well-used
>> format (which recursively compiles all java files in the directory):
>>
>> $ cd myJavaProject/src/
>> $ javac `find . -name "*.java"`
>>
>> no longer works because it will attempt to compile the pristine
>> copies. or this command (which moves all HTML files to your web server):
>>
>> c:\> xcopy /s /e webstuff\*.html d:\myserverdir\
>>
>> won't work because it copies the wrong (pristine) version of the file.
>> yes, you can 'export' in this case but you get my drift. this was not
>> a problem with CVS because CVS does not have pristine copies.
>>
>> any tool that recursively scans directories has this potential
>> problem. and the potential to modify the contents of the .svn
>> directory. that means practically every build script/tool/IDE/file
>> manager out there.
>>
>> storing this directory in a compressed file would prevent these
>> problems, as the compressed file would be treated atomically.
>>
>> hth,
>> alvin
>>
>>
>> daniel@etrak-plus.com wrote:
>>
>>> 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
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>

-- 
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