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

Re: Another working copy library

From: Danny van Heumen <danny.vanheumen_at_hccnet.nl>
Date: 2007-01-27 19:34:59 CET

Filipe Fernandes wrote:
> 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.
Like Michael Sinz already said, you only have to search for 1 specific
directory name inside every directory you crawl, so it can be done
pretty (very) fast.

> 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 not that big a problem I think. It's true that they would have to
search to the top. But in case of a working copy it's sufficient to
remember what the root is (and special cases like ignored directories
and such).
Once you know the location of a root of the WC it's (almost) as easy as
comparing the start of the current WC.
And TortoiseSVN already uses caching (TSVNCache.exe) for the current
directories to remember modifications. So it would only take a little
bit more information.

> 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.
The problem is that it's not just about the convenience. Leaving these
directories creates problems for some programs. Like packing programs,
they package the entire directory ... include the '.svn' directory. And
if I understand David correctly it's also a problem for programs that
run all subdirectories thinking they are plugins while '.svn' is not a

Considering everything I think it's a small price to pay if the '.svn'
directories are removed.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 27 19:35:39 2007

This is an archived mail posted to the Subversion Dev mailing list.