You only have to fix what's broken, which is not much. Certainly it
isn't "everything".
I think most of this thread belongs on the dev list. If it's not a
bug, per se, then perhaps those who are interested should become
developers and code up this enhanced functionality.
Or perhaps switch to svk. I understand it doesn't have these issues.
Alvin Thompson wrote:
> 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
>>
>
---------------------------------------------------------------------
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:36:07 2004