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.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 27 18:57:08 2007