RE: Status information -- needs a better solution

Wow -- I'm a little scared to post again, but let me start off saying I'm
very sorry if you took this as offensive. I'm not trying to insult anybody
or deride anyone's work. I'm just expressing a problem as we see it (and I
was careful to say this was clearly not an opinion others would necessarily
share).

All software has problems and discussing the weaknesses and potential
solutions seems like part of the process. I guess you take any negative
comment about the tool as a personal assault and given that, I'm very sorry
for not approaching things more gently. Let me be clear that we think TSVN
is a very impressive tool and being open source of course the efforts are
lightly funded at best. But would you really rather than folks who find
weaknesses in TSVN just shut up and go away? Certainly in future that'll be
my choice so you don't have to worry about me riling things up again, but I
think the tool will ultimately be the weaker for it.

I'm not really sure that you're interested in discussing this rather than
just flaming me again, but I'll try to respond to your points.

First up, I don't see the status information of TSVN as being critical.
Clearly you do, but I see the explorer integration as being the critical
feature--not the same thing and I could happily live without the current
status portion.

For you 5-20MB of RAM is no big deal. Cool -- I'm not saying it is a big
deal to everyone. But for me adding a process that consumes around 5% of
RAM and is running all the time is a big deal. As you say, there are lots
of processes that wish to take that same small hit on your system
performance and when you total them up it's not unusual to be losing 20% or
so in RAM (generally much less in CPU) to these background processes and
then you pay for time swapping them in and out etc. So for me, I don't take
those hits unless there's a significant benefit and for us the status
portion of TSVN adds very little value, while the rest of the tool adds a
lot of value (and ZERO ram/cpu hit when it's not actively doing SVN tasks).

As for the rant that my proposed solution wouldn't be simple--I'm not sure
what to make of that as you then seem to suggest right after it that the
tool is already close to supporting it. Of course, I haven't looked at the
code for this but in general disabling a capability isn't that hard. Maybe
for TSVN it is and the rest of the code won't work if the status icons
aren't filled in correctly--sure it's possible and if that's the case then I
apologize again for suggesting it would be simple.

And again, please accept my apologies for hurting your feelings. That
really wasn't the intention,

Doug
 

-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com]
Sent: Thursday, February 02, 2006 11:14 AM
To: users@tortoisesvn.tigris.org
Subject: Re: Status information -- needs a better solution

Douglas Pearson wrote:
> We're actively evaluating SVN and its clients for our business and
> Tortoise looks excellent in every regard except for what seems to us
> its rather absurd approach to status information.

What you call here 'absurd' it the key component of TSVN. If you don't like
it, please use another client and don't insult us and the many many hours we
spent working on this project.

> The "new" solution of having the TSVNCache process crawling slowly
> round the file system updating the status icons as it goes seems
> practically useless to us as this means there is no way to know when
> status information is actually correct (except for leaf nodes in the
> folder tree). It's a bit like having the speedometer in your car
> always showing a value with the promise that "sometimes this is how
> fast you're actually going".

For me, it's pretty accurate.

> The price for collecting this inaccurate is a process that's always
> running and consuming 5-20MB of RAM.

Wow! A process that's consuming about 1% of CPU and 5-20MB RAM! Call the
police!
Just open up the task manager and check the many processes on your system.
For most of them, you don't even know what they're for, but they still use
more CPU and RAM than the TSVN cache.

> Presumably many people don't share our reaction or the situation would
> have changed, but can we suggest a simple solution:

Ok, you still have to learn a lot.
First of all, what makes you think your solution would be simple? You don't
know anything about TSVN, its userbase or the code. So how can you make such
an assumption? Can you even begin to imagine what it would take to implement
that? Or deal with the whole userbase later on because of that change?

> a) Allow for the status crawler to be disabled completely (so status
> icons would only be shown for leaf nodes in the tree and nowhere
> else--perhaps just an icon to show that a folder was under SVN
management).

Check the settings dialog: you can exclude any path you want from showing
the overlay icons. If you then remove the TSVNCache.exe file from the TSVN
installation folder, you don't have to worry about the cache anymore.

> b) Provide an explicit "status" command on the context menu to run
> "svn status" and display the results.

Ever heard or tried "check for modifications"?

> This would remove the TSVNCache process hit and status information
> would always be correct (if less complete).
>
> Any chance of this happening?

Next time, if you really want something in TSVN, make sure you don't insult
the whole project with your mail. It really hurt me.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org