> * It takes a long time for some servers to respond. Which
> would make the overlays slow, and therefor the explorer way
> too slow to work with.
I am not suggesting anything that does checking on-the-fly, which would
slow down explorer. I am merely suggesting a periodic check helps users
quickly identify things that have been changed elsewhere. It does not
have to be "live," users can accept a certain level of granularity,
especially if that level is configurable. Say, once every 5 mins, or 60
minutes, or once a day. Any user who cannot tolerate this level of
granularity is free to right-click and check for modifications.
This periodic checking helps people notice something was modified, that
they didn't expect to be modified. Hence, they were unlikely to ever
check for modifications unless the check was automatic and silent.
> * There are only 12 overlay slots available in explorer, and
There is already a lock overlay, so there is no need to use another for
that. If people don't like the idea of creating a new overlay for
"remotely modified" it is acceptable to change the meaning of "locally
modified" icon, and let it be "locally or remotely modified." No need
to use 2 new overlays, there is only an optional need for one.
> * You can use the post-lock hook script to send out a mail to
> every developer if you want to know who has which files locked.
> * You can use the post-commit hook script to send out commit
> mails. Then you know that a file is out-of-date too.
This email idea is more unfriendly than right-clicking and check for
modifications. If there are thousands of files under revision control,
with dozens of users working on a project, it will be impossible for the
users to keep track of that many emails.
> You can of course work on such a feature yourself. But be
> prepared to have your patch rejected if it slows down the explorer.
As I said, I don't intend for anything that will slow down explorer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Mon Apr 24 19:11:43 2006