[Cross-posting to dev_at_subversion.apache.org]
On 10/11/2010 06:07 PM, Anthony Falabella wrote:
> Why does the code need to look at all at the parent dir above where a
> checkout is being performed? Not only might the parent dir be not
> writable, but in our case even looking within that dir is an expensive
> operation. Subversion 1.6.6 through 1.6.12 are essentially not usable by
> my team until this is addressed.
This behavior was added to help folks who are using 1.6.x clients know that
they need to upgrade their software when they attempt to run Subversion on a
1.7-or-newer working copy. (Because Subversion 1.7 won't have the .svn
subdirs anywhere except the very root directory of the working copy, it's
not sufficient to look only in the current directory.)
Why does checkout need to do this? "Need" could be debatable. Under the
hood, though, a checkout is just a special form of an update. Update needs
to check parent directories (so it can integrated newly fetched
subdirectories into their parent working copy). So it happens that checkout
behaves the same way.
I'm very unhappy with just how far-reaching this "for your own good" check
is. I keep my home directory under version control, and because I'm a
Subversion dev, my working copies tend to be of the latest trunk format. So
in my situation, I can't use Subversion 1.6 *at all* anywhere in my home
directory because it *always* searches parent directories and *always* finds
a 1.7-ish .svn directory in ~/.svn. I pity folks that, say, keep their
system's root directories under version control.
Some time ago I fixed the trunk code to not be so similarly far-reaching --
as a result, I was able to finally create 1.7 working copies inside of 1.6
ones. But I've not yet attempted to fix the reverse in the 1.6 line.
Just so you know, you can force 1.6.x to *not* perform this check by setting
the following obnoxiously long environment variable:
Insert warnings, disclaimers, etc. here.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-10-12 03:20:09 CEST