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

Re: Strange status if .svn folder removed

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 28 May 2010 00:30:49 +0300 (Jerusalem Daylight Time)

[ fixed leading "> " signs ]

Hyrum K. Wright wrote on Thu, 27 May 2010 at 16:17 -0500:
> On Thu, May 27, 2010 at 3:40 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>
> > > > Will per-directory .svn's remain as an option in 1.7+? (I thought
> > > > yes...)
> > >
> > > Not to my knowledge. I wasn't aware of the use case (aside from
> > > severable working copies) that engendered this need.
> > >
> >
> > How are the 1.7 WC libraries going to determine if a folder is part of a
> > WC? Are they going to have to walk the file system backwards all the way to
> > the root? That seems like a bit of a perf hit for large projects with a deep
> > level of nested folders?
> >
>
> "deeply nested" usually means only 10-15 folders. Recursing up to find the
> root of the working copy is a one-time operation during the course of an
> invocation of 'svn' on that working copy. As such, it's essentially a free
> operation.
>

How would recursing interact with symlinks into working copy dirs?
(I know we it have been discussed before; a pointer would be appreciated)

eg:

    svn co $SVN_TRUNK trunk
    ln -s trunk/notes notes
    cd notes
    svn st

Daniel

> Also, compared to all the other traversal of the working copy that happens
> in 1.6, but which will be eliminated in 1.7, it's a tradeoff we're willing
> to make.
Received on 2010-05-27 23:30:35 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.