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

Re: .svn directories considered harmful :-).

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-02-25 05:22:20 CET

"Thomas A. Horsley" <tom.horsley@att.net> writes:

> As a potential new user reading about subversion for the first time, I was
> immediately struck by what an incredibly bad idea the .svn directories seem
> to be. Wouldn't they be safer if I could do something like set an
> environment variable named (perhaps) SNV_ROOT and then have the .svn
> directories created under the SVN_ROOT directory tree instead of directly in
> my working copy?
> My work area is where I live all the time, where I fat finger commands,
> where I run perl scripts to automatically edit all the files in the
> directory tree, etc. With the .svn directories mixed in with my work area, I
> have to constantly be on guard. With them off in a separate parallel
> directory tree, I'm much less likely to do something stupid to them. Having
> the .svn directories in my work area seems a lot like logging in as root all
> the time :-).
> Just 2 cents from the first impressions of someone who knows nothing about
> subversion except what he read in the book the last couple of days.

There have been several expressions similar to yours in days gone by
-- the voices are being heard. But the decision to use in-tree .svn
areas was made for two main reasons:

   1. Having in-tree admin areas means you can pick up and move a
       working copy to a different location and preserve that admin
       information. So if you do an 'svn checkout' to /some/path, and
       then later decide you wish your working copy was elsewhere, you
       just use 'mv /some/path /some/other/path' and that's that.

   2. Users of CVS (who are, ultimately, our primary market) will be
       familiar with this practice, as CVS uses in-tree admin areas.

I'm not saying the topic won't be revisited. I'm just saying the
decision wasn't made without thought.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 25 05:22:24 2004

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.