On Mon, Oct 11, 2010 at 9:19 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > [Cross-posting to d...@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.
You did not quote the part where he says for a checkout of 2000 files it does this check 2000+ times. That seems like it ought to be fixable and is not an acceptable change for us to have added to the 1.6.x releases. -- Thanks Mark Phippard http://markphip.blogspot.com/
