the whole concept of SVN is to provide a replacement for CVS which
addresses its major limitations. as this list has shown, this *is* a
major limitation. we have the capability to address this without
impacting the feature set. why not address it? "because it's a bigger
change than i feel like doing" is not a valid answer.
but even if it were difficult, wouldn't it make more sense to modify SVN
to play well with other programs than to modify every other program out
there to play well with SVN? the whole point is to have SVN universally
accepted. that acceptance would come easier if SVN actually worked with
the most popular IDE on the planet.
one of these days when i'm not so lazy i'll look at the code. but i
imagine the impact would be negligible once you obtained a different
stream. if this is not so, you probably need to do a better job of
abstracting that stuff, anyway, since SVN may need to run on something
other than a regular file system sometime in the near future (hint, hint
;) .
-alvin
Brian W. Fitzpatrick wrote:
> On Mon, 2004-03-08 at 11:45, Alvin Thompson wrote:
>
>>um, i'm not following you. how is it high-cost in development resources?
>>there are only about a billion libraries out there that facilitate
>>compressed folders, and even a 6-year-old or older processor can keep
>>up. it probably wouldn't significantly change more than a few lines of code.
>
>
> I so *totally* beg to differ. It would require a lot of work to change
> libsvn_wc to use a compressed .svn directory. I think that you're
> grossly underestimating the effort required.
>
> Now if you'd like to provide a 'low-cost' patch that does this, passes
> the test suite, and doesn't cause a huge performance problem, I'll be
> more than glad to eat my words. :-)
>
> -Fitz
>
--
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:01 2004