[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: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2003-05-16 22:06:27 CEST

On Thu 2003-05-15 at 18:45:06 -0500, cmpilato@collab.net wrote:
> "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 it is bothering? Of course, everyone could add that grep. But
why make it harder than necessary? By your argument, why do we have
the .svn-base ending at all? I exagerate, I know. But you get the

As long as it is relatively easy to hide .svn's internals, I see no
reason not to do it. E.g.

  $ gzip -rd .

will go recursively through all files and uncompress them. I presume
not a lot people would expect that to override their (un)compress
setting in their svn config file. And certainly having to type

  $ find . -name "*.gz" | grep -v '\.svn/' | xargs gzip -d

isn't that intuitive. Quite some developers I know don't bother to
know enough script-fu to come up with something like that. (Yes, I am

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

I don't get your argument. Of course, if we'd to give up too much to
protect them, I'd agree. But why wouldn't you install a safety guard,
if you easily can?

Rather than that, I would be willing to follow an argument that the
possible harm (mainly unknowningly uncompressing text-bases) is so
small, that it is not worth bothering with its effects.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 16 22:07:21 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.