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
.svn.
> >> This *could* slow the Windows Explorer down, since it will call into
SVN
> >> 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
doesn't
> >> 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
public.
>
> 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
things.
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