(1) I do not see why such a feature could be implemented, and disabled by
>> This would be a win-win situation: on one hand, performance on SF-like
>> public SVN servers will not suffer. On the other hand, those that really
>> want and need this feature can enable it on a per-installation basis, and
>> get the feature they need.
> And what if I as a user switch on this feature, having been advised by the
> manuals ("switch this feature on if your server is on the LAN") having
> totally forgotten that lurking around on my harddrive are working copies of
> open-source projects (including TSVN) that I checked out long ago. What if
> thousands of other people make that same mistake? we all unwittingly are
> bombarding the servers with svn status requests.
then make it a property on the repository that the client checks to
determine whether it is allowed to crawl the repository.
> Now supposing you ran the status cache in shell mode instead of default
> mode, it would presumably have to do (remote) status request every time you
> opened a directory in explorer - I reckon explorer would become unusable and
> the good people who develop TSVN would be bombarded with complaints...
no that would be stupid.
the 'server cache' would run in the background, hitting the repository
every x minutes.
its not as if svnserve | apache run like dogs when they are being bombarded
with read requests.
(4) I think developers (myself included..) tend to sometimes fall in love
>> with the elegance of some solution, and disregard what the actual users,
>> which the product aims to eventually serve, want. Without exception, in the
>> last 3 companies where I introduced Subversion and TSVN to replace a
>> version control system, this is the #1 feature that users were missing.
>> This feature gives users a warm fuzzy feeling, and the illusion that they
>> know what's going on in near real time, and they love it, regardless of the
>> actual contribution it makes to the actual development effort. That's really
>> the main reason to enable this feature in my opinion.
>> We are all humans and this warm fuzzy feeling helps "sell" TSVN very
>> I would defiantly and absolutely love to see this feature in TSVN. :)
> I reckon that if you rely on overlays to show remote status it leads to a
> false sense of security. How can you be sure its absolutely up to date, you
> can't even be that sure with the local status (although it's pretty quick on
> a good PC). If you really want to now "right now" that a file is remotely
> unchanged to you need to perform the check "right now" and that's what the
> check for modifications dialog does.
the same can be said about the modified overlays, you only know the state of
your WC when you do a check-for-modifications or similar operation that
ignores any state and crawls the wc.
just my 2c
Received on 2008-07-22 23:30:07 CEST