[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Compressed text-base, take 2

From: Sander Striker <striker_at_apache.org>
Date: 2003-05-16 02:03:51 CEST

> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> Sent: Friday, May 16, 2003 1:45 AM

> "Sander Striker" <striker@apache.org> writes:
>> Hmmm, I don't agree. The .svn dir should be private to SVN. Anyone touching
>> it is risking breakage. I'd rather keep the .svn-base extension to make
>> sure we aren't mathing on *.gz, so that users don't accidentally do stuff to
>> it.
> Dude, this is silly. I *constantly* use 'find -type d', and I know
> that I have to pipe that through 'grep -v .svn/'. Why can't folks
> doing 'find -name '*.[ch]' do the same piping?

Because that is requiring users to handle something they shouldn't have to
handle. Why burden the user with something we can so easily prevent?
Let the ones doing private working copy dir manipulation go through the
trouble, but not your average user.

Don't forget you are a developer with a lot more knowledge about what
is in .svn than can be expected from a user. And, IMO, a user shouldn't
have any knowledge about what is in there, apart from the fact that SVN
needs it.
> We're already marking the text-bases as read-only, so I'm sorry, but I
> think your concern is just overboard. We simply can't protect
> everyone in the world from shooting themselves in the foot in any one
> of several ways.

Exactly. We've added the .svn-base for a reason. If we now go back
to .gz, that will be a regression IMO. And FWIW, I feel the read-only-ness
is a bit overboard personally...
> With great shell comes great responsibility.

With writing software for the masses this goes the same.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 16 02:05:08 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.