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

Re: [PATCH] Stop resurrecting deleted files in ~/.subversion

From: <epg_at_pretzelnet.org>
Date: 2003-01-25 02:12:54 CET

=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= brane@xbc.nu writes:

 Well, tough. What are you removing that file for? Does it bother you so

No, NOT tough. That's *my* directory. It isn't private svn
data. It's mine. And i don't need a fucking README in it. Some
people won't need a config file, or a servers file, or any of the
other files that may one day be there. And i don't need my svn
st output cluttered with garbage when i check the status of that
directory. And papering over the problem with an svn:ignore
property is not the answer. Subversion just needs to stop
leaving its droppings in *my* home directory.

 This seems like a very, very fragile way to go. *If* it turns out that
 we really need this feature -- something I'm not sure about -- then it's
 be much better to test for ~/.subversion/README, just like we test for
 .svn/README in the WC. That would at least give us a measure of
 confidence that Subversion created the config directory, not someone else.

Nope. Subversion did *NOT* create my .subversion directory. *I*
did. When i checked out my dotfiles on this machine. And it's
none of Subversion's business who created .subversion. It's *my*

What exactly is fragile about it? Subversion should not
*require* a .subversion directory. In its absence, it can make a
reasonable effort at creating one, but no more. When i request
operation foo and it fails to create .subversion or some file
therein, it should not fail. Because i didn't ask it to leave
droppings; i asked for operation foo. If a .subversion already
exists, then Subversion has ALREADY BEEN CONFIGURED. To leave
droppings on that existing configuration is wrong.

And yes, that means you can't cleanly add new files to existing
.subversion directores. That's tough luck on Subversion's part.
My home directory is not a location for it to drop documentation
and example files. Documentation and example files have their

I accept the convenience of Subversion making a reasonable effort
at setting up .subversion. Note that i did not send a patch
disabling this entirely. I simply restored control of the
directory to its rightful owner. Once more, with feeling: this
is *my* directory.

Eric Gillespie * epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:16:23 2006

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.