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

Re: Using only one .svn folder in repository root

From: <kmradke_at_rockwellcollins.com>
Date: 2007-11-27 19:04:30 CET

Joachim Durchholz <jo@durchholz.org> wrote on 11/27/2007 11:51:09 AM:
> kmradke@rockwellcollins.com schrieb:
> >> with a root .svn, traverse up the directory hierarchy to find the
> >> This *could* slow the Windows Explorer down, since it will call into
> >> whenever you look at the properties of a file - though the slowdown
> >> would be negligible if SVN cached the whereabouts of all .svn
> >> directories (though I'd want the caching code to shake out a few more

> >> bugs before doing that, the left pane of Windows Explorer still
> >> update properly for me).
> >
> > Oh, I was thinking at the root of the tree, not completely outside the
> > tree. I didn't explain that well.
> That wouldn't change anything.
> See, whenever Windows Explorer shows the Properties dialog of a file, or

> its context menu, it calls into the SVN hook dll.
> To do the right thing, the SVN dll has to decide whether that file is,
> in fact, part of a checked-out repository tree (for the Properties
> dialog, it's the decision whether the 'Subversion' tab should appear,
> for the context menu, it's the decision which of two variants of the
> context menu should be shown).
> To find out whether the file is part of such a repository tree, the SVN
> dll would have to traverse the directory tree up to the root to see
> whether there's a .svn directory somewhere. This check would have to
> happen for every file in the Windows directory; in fact the check would
> require more disk accesses for non-repository files, because then the
> search would go all the way up to the root directory.
> Windows Explorer is the primary means of accessing files, and if such a
> lookup has any noticeable performance impact on Windows explorer, that
> would be a heavy factor against the use of TSVN.
> To check that out, somebody would have to add some directory traversal
> code to TSVN and check it out on a machine with marginal performance.
> You'd also want to lose a few thoughts about where exactly the search
> should end - there's stuff like network drives, the Desktop, etc., which

> don't have the exact Posix semantics of a filesystem directory.
> BTW this might also have ramifications for the handling of the
> svn:externals property.
> Note that I won't speak for or against such a feature. It's just that
> these problems should be solved before rolling it out to the general
> However, if I were a project leader, I'd flatly refuse to implement
> this. Too many potential sources of trouble, and I'd prefer a slightly
> awkward TSVN to one that occasionally loses data or slows down Windows
> Explorer.

Hmm... How about a third option:

Just a single .svn file in each directory that points to the location
of the working copy meta data location. This has other ramifications I'm
sure no one has thought about yet.

I'm not suggesting anything, just thinking out loud. And I agree, if
performance or complexity is sacrificed, it is a big -1 to implement these

Kevin R.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 27 19:05:27 2007

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.