Re: Feature Request: 'Needs Update' Icon Overlay

Aviel wrote:
>>> (1) Enabling this feature in TSVN only on a per-URL basis would
>>> solve "all repositories are the same" problem suggested before.
>>> You would
>>> only enter a list of URL on your local LAN to poll. If you don't
>>> enter a SF URL, your SF WC would not generate polling traffic.
>> That doesn't stop someone else from abusing it.
>>
>
> AFAIK nothing stops you from abusing a public SVN server. This feature may
> make it a little easier to do, that's all. If this is a concern then
> it is possible to set a lower bound on the poll interval (say 3 minutes) to
> limit the traffic. But other than this, enabling this feature in TSVN
> is not different than what the CommitMonitor program does and the latter is
> considered legitimate usage. All you are doing is letting people who
> need this functionality, and would do this "Abusing" one way or
> the other, do it main stream inside the same GUI, instead of having
> to use multiple programs.

CommitMonitor uses a robots file, servers can limit the polling interval
themselves:
http://tools.tortoisesvn.net/svnrobots

>>> (2) If Icon overlays are not technically possible (too few Windows slots)
>>> I'll
>>> settle for remote status to show in Windows Explorer's 'SVN Status' column.
>>> Just give me some sort of solution that I can use and that is integrated
>>> with
>>> TSVN. A 'Needs Update' text in the 'SVN Status' column is all I basically
>>> need (that's what we had with our previous VC tool).
>> You say you're against needing "additional configuration" but enabling
>> this column in Windows is additional configuration too.
>
> I think users who need this feature are willing pay this extra configuration
> (in fact they don't have to, site wide admin can enable it by default, they
> would never know).

Vista doesn't allow such columns anymore.

> A final note; it seems that TSVN is trying to be both a tool
> and a usage policy,
> which I don't think is right. Just give us (the site admins) the
> options and let us enable and disable options depending on our
> site's policy, instead of setting "one usage policy fits all"
> approach and hard-coding it to the GUI. For a corporate user with
> no performance
> issues (GBit lan, very strong
> servers, etc) I don't care about the same things as the open source coder
> developing against a public server. On the after-noon though, I might work
> from home on open source and then I do care. But the usage model differs and
> TSVN should allow for this.

In an ideal world, you would be right.
But this is not an ideal world. Once we implement _any_ feature, users
expect that feature to work fast and reliably. And if it doesn't, they
come complaining here over and over again.

Need an example?

Enabling the overlays for network drives. It's disabled by default,
because it is slow and unreliable. Users have to explicitly enable that
feature, and they're warned about the possible performance impact.
But that doesn't matter. It's slow on network drives, and they come here
complaining about that. We can tell them to deactivate the overlays or
move the working copy to the local harddrive - it won't help: that's not
what they want.

another one:
repositories on network shares. Every time you try to create one, TSVN
show a warning dialog. The only reason that feature is still there is
because it's an easy way to create repositories which are then served by
apache (i.e., the shared folder is the SVNParentPath folder, and that's
where the new repo is created).
But do people listen? No!
And then when their repo is hosed beyond repair, they come here
complaining about crappy tools. Because TSVN allowed them to do that.

So yes, TSVN has to act as a "usage policy" too. It has to do everything
it can to prevent users from shooting themselves.

Stefan

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net