David Glasser wrote:
> [snip]
> If we're going the root of "no important information in .svn
> directories", then we really shouldn't require .svn directories for
> the sake of a tiny optimization.
Actually... if I understand how TortoiseSVN works... this is a very big deal
for GUI programs that visually report on changes within a working copy.
If there is no .svn directory n-levels down a working copy, there's no way for
GUI programs like TortoiseSVN to know that it's looking at a working copy
unless it traverses up towards the root and finds a .svn directory within the
root of the working copy.
Each time (every time) an explorer window is opened, TortoiseSVN would
literally have to crawl to the top to find out if it's in a working copy.
It's trivial to crawl to the root (unless your very deep), but it would have
to be done every time to make sure.
TortoiseSVN could add caching to remember previously found working copies for
faster reporting but that seems a hell of a lot dirtier than simply providing
a .svn directory with info as to how many levels within a working copy the
current folder is situated.
It's my opinion that leaving the .svn folder in place for each versioned
directory is the small price to pay (to accomidate GUI programs like
TortoiseSVN) in light of the serious performance increase you'd get with a
sqlite database found in the root of the working copy for both GUI programs
like TortoiseSVN and command line tools that come with Subversion.
filipe
ps: I heavily use TortoiseSVN, but in no way participate in it's development
so I could be seriously wrong about the above. I doubt it though ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 27 01:56:12 2007