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

Re: found the PDH problem

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 27 Feb 2011 12:40:07 +0100

On Sun, Feb 27, 2011 at 02:34:44AM -0500, Greg Stein wrote:
> Hyrum,
>
> On IRC, we also talked about trying to remove stat() calls from the
> parse function. Upon reflection, that won't be possible. If the given
> path is below a wcroot, then we cannot simply return that wcroot. We
> need to see if the path is in a CHILD wcroot (think: nested wcroots in
> a disjoint working copy). Thus, we need to examine the disk to look
> for the closest wcroot to a given path.

Greg,

it would be really interesting to know your opinion on this thread,
because it is slightly related:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201102.mbox/%3C20110223153217.GG29291@jack.stsp.name%3E
(same message in a different archive: http://svn.haxx.se/dev/archive-2011-02/0789.shtml)

> If we continue to keep a mapping of dirpath->wcroot, then we can avoid
> future stat calls after the first (effectively, it is a cache). For a
> file, we will always need a stat since the fname will not be in a
> memory structure. When the file is discovered, the parent directory
> may be in the cache and no further stats will be required.

I think the current local_abspath->wcroot mapping approach is broken for
svn:externals, as long externals have their own wc.db. There are two
valid results in that situation.

It's possible that what the code does right now is not what's intended,
but on the surface it looks more like a gap in the current design than
an implementation error.

Thanks,
Stefan
Received on 2011-02-27 12:40:51 CET

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.