On Mon, Oct 11, 2010 at 9:19 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> [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.
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/
Received on 2010-10-12 14:38:31 CEST