> Apology accepted :)
> And sorry for me being rude. As I said, I'm having a bad day. And your
> mail had some 'trigger' phrases in it that just made me snap.
OK, well I'm glad we've managed to mutually bring the temperature down and
your workaround does indeed seem like the best solution that's currently
available, so thank you for that.
I would just like to take one more (gentle I hope) attempt to discuss this.
The key point is that it's not all overlays that are a problem--just the
folders. The status information for files will always be correct (within the
limits of a multiprocess world), but let's look at the folders.
Given a TSVN folder with an icon overlay what can we say about that folder's
contents?
The correct answer (I believe) is nothing--unless we know a lot more about
how that icon was generated (e.g. that we were backing up through the folder
tree refreshing as we go or that the tree beneath the folder is small or
that I just ran an update). The reason we know nothing is that we don't know
if the status is currently up to date or if it will update at a future time
and the time to compute a new value is arbitrarily long (proportional
presumably to the size of the folder tree beneath it).
An example of a key question we can't answer accurately (based on the
overlay) is:
Do I need to commit this folder?
However, (dangerously in our opinion, esp. for more junior developers) it
*appears* that you can answer these questions based on that icon, but really
you can't.
This is not a unique problem or failing within TSVN--this is just a very,
very hard problem to solve. It's the same reason, for instance, that Windows
can't report the size of a folder immediately--it instead has to search on
demand to compute it and those guys own the file system code.
However, for any folks who agree with our view that you cannot correctly (in
general) infer anything from the status overlay on a folder then the role of
TSVNCache.exe becomes very questionable as it's primary reason to exist (as
I understand it) is to fill in exactly those overlays.
Remember again, I'm not saying all icons and overlays are bad--just ones on
folders. If the overlays are limited to files then there's no need to run a
crawler in the background over the whole tree, there's no 24/7 performance
hit and all status information is always valid (again within the limits of a
multi-process system). It could mean that opening a folder of SVN files
would take a little longer but that calculation is bounded by the number of
files within the folder, rather than within the entire tree (and users
understand that folders with 5,000 files take longer to open already). It
would also mean that you'd need to run an explicit command to answer the
question "Do I need to commit this folder" -- but that's better (in our
opinion) than thinking you know the answer when you really don't.
I realize that writing TSVNCache was a major effort and the crawling
capability was the big 1.2 addition, and I'm not expecting you (or anyone)
to discard that effort or write a whole lot more stuff to support this, but
in truth, I think if you could revisit the question of what value is gained
by crawling over the file system you might find that this is a case of where
"less is more" and think about supporting a solution that does a bit less
and as a result is (for at least some subset of users) more useful.
(Also, BTW, I did search the archives before my original post and there have
been other requests to allow for disabling TSVNCache before -- so while this
may not be a popular position it's not unique).
I hope I've not said anything here that sounds derogatory or that I'm coming
off as saying this is the only view to hold on this stuff -- again, my
intention is to focus on the tool and how (we believe) it could be
constructively improved in a way that (hopefully) doesn't require adding
major new capabilities.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Feb 3 02:27:11 2006