Gal Aviel wrote:
> Hello All and thanks for your reply!
> First and foremost, I did not intend for the server to push anything,
> rather I was referring to the case where the SVN client is
> polling the server.
> Please consider my following arguments:
> (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.
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
> (2) Indeed you can achieve similar results via CommitMonitor, but
> with much less comfort as this solution is not integrated inside TSVN.
> So why not
> enable this feature inside TSVN for those who want it? In principle no one
> is blocking you from polling the server every 2 seconds anyway.. you
> can kill it performance-wise even without TSVN's help.
You could deliberatly poll a server every two seconds, but with this
feature you could accidentally poll several servers you didn't know about.
> (3) I don't think a huge public server like SF or tigris are the general use
> case for SVN servers.
> In most cases I've seen the SVN server is hosted
> on a machine which is usually an overkill for the task at hand.
> SVN teams I've seen are small (10-20 active users at all times..).
> The kind of performance impact that this polling will generate
> is probably negligible in most use cases. At least in our case, we
> are more that ready to suffer this impact, in order to get the behavior
> we need.
> (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.
I've been using TSVN for 3 years and I always find that this issue
confuses new people for about the first day then they get used to it
(then they get to like it? I don't know but I certainly like the SVN
philosophy that you only get bothered by remote status when you go
looking for it...)
> Just my 2 cents..
Mine too! Good luck with your feature request!
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-22 18:06:57 CEST