2008/7/22 steven higgan <steven.higgan_at_gmail.com>:
> comments inline
>
>>> (1) I do not see why such a feature could be implemented, and disabled by
>>> default.
>>>
>>> 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
>>> previous
>>> 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
>>> easily..
>>>
>>> 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
The tools are already there. You have the CfM dialog. You have commit
emails. You have Stefan's CommitMonitor program. The only way it could
be any more integrated is if the overlays reflect the local and remote
status.
That sounds great, but think about it more carefully. Now how many
combinations of local status and remote status can you come up with?
How many different icons can you easily distinguish? And given that
Windows only allows about 12 overlays in total for all applications,
how is that going to work? And what about remote file renames? Remote
file adds? You may not even have a local file to pin the overlay onto,
so you only get half a story.
TortoiseSVN has to operate within the boundaries of the features
Subversion offers, and the restrictions placed on it by being a shell
extension. What you are asking for does not fit well with either of
these constraints.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-23 00:24:07 CEST