[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature Request: 'Needs Update' Icon Overlay

From: Aviel, Gal <galaviel_at_yahoo.com>
Date: Wed, 15 Oct 2008 09:48:17 +0000 (UTC)

> > (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.

> > (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).

>
> > (3) CommitMonitor is a great tool however it is not integrated with TSVN,
and
> > requires a separate installation and post-install configuration. Installing
> > it x15 times for each member of my team and configuring it is not a fun task
> > Also users don't understand why they need to install more than 1 program
> > to do version control.
>
> CommitMonitor isn't *needed* to do version control. *You want* it (or
> something like it) so that people get notified, to make your
> installation a push configuration instead of a pull. Most of my users
> would consider it an annoyance to have icons changing so frequently.
>
> Have you considered publishing RSS feeds and/or sending notification
> emails in your post-commit to inform people that an update has been
> made in the repository?

Not really, people in my group are hardware designers and
don't even know what
RSS is. For them, working with one GUI is more than enough.

> > (5) Please understand that some users who use TSVN are not programmers,
> > they are not proficient with VC tools and their methodology, they just
> > want things to work ... they won't go out of their way to install
> > a second
> > product (CommitMonitor) and config. it and they don't understand
> > and don't care about many points raised here which are implementation
> > related.
>
> This I don't get. The end-user doesn't have to understand everything
> about Subversion and VC methodologies. But they do have to understand
> how to use the tools required to do their jobs. I don't understand
> desktop publishing, but I'm required to use MS Word to do my job. I
> don't understand 90% of what Excel does, but I'm required to use that
> to do my job.
>
> If TSVN is required to do your job, I expect a basic level of
> competence.

you are expecting too much :)
In a perfect world, where all TSVN users are tidy and clean
software engineers, there would be no problem. But most corporate users don't
care about VC, for them it's something their manager told them to do.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-10-15 11:48:35 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.