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
Received on Mon Mar 8 22:18:41 2004