Feature Request: 'Needs Update' Icon Overlay
Gal Aviel
A repeating request that has been made in the last 3 companies that I've worked
in is the ability to get the remote status of files "pushed" to the client.
For example, in the Synchronisity's DesignSync tool, you get a "Needs Update"
indication in the 'status' column of their GUI client.
For TSVN, I guess this can be done via a new Icon Overlay, and having the Windows
Explorer TSVN 'status' column show 'out of date' or 'needs update' in addition
to the current local-only status that it's showing ('normal', 'modified', etc).
In my opinion, this is one obstacle that keeps TSVN from being a really the
perfect version control tool.
Any comments/ideas are welcome (I'm considering adding this to the feature list),
Many thanks in advance,
Gal.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org
Lübbe Onken | RA Consulting
Hash: SHA1
Hi Gal Aviel,
You wrote:
> Hello All,
>
> A repeating request that has been made in the last 3
> companies that I've worked
> in is the ability to get the remote status of files "pushed"
> to the client.
A real "push" would require the server to know all the clients that are connected to its repository. Doesn't make much sense IMO.
> For example, in the Synchronisity's DesignSync tool, you get
> a "Needs Update"
> indication in the 'status' column of their GUI client.
>
> For TSVN, I guess this can be done via a new Icon Overlay,
> and having the Windows
> Explorer TSVN 'status' column show 'out of date' or 'needs update' in
> addition to the current local-only status that it's showing
> ('normal', 'modified', etc).
An additional icon overlay that shows this status reliably would require a constant server connection, bandwidth and CPU load. Subversion is designed to be used offline and to only contact the server when necessary. Imagine sourceforge with a zillion clients constantly pulling for status information... OUCH...
> In my opinion, this is one obstacle that keeps TSVN from
> being a really the
> perfect version control tool.
It already is :)
Use the "check for modifications" dialog for your purpose. This only contacts the repository when neccessary.
You can set up a post-commit e-mail hook on your server which tells ("pushes") all the signed up people what has changed and that they (sh|c)ould update their WC.
> Any comments/ideas are welcome (I'm considering adding this
> to the feature list),
Check the mailing list or the bugtracker. You'll probably find that request somewhere. We have already discussed this subject more than once.
Cheers
- - Lübbe
- --
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFIhZPgm8gezyP1EasRAjw6AJ4jl5mjIrlSbeDdTnGfrkieeTcC0wCeMhRv
HEWJvnhlTc1ivOh9sSi+EFA=
=eF9H
-----END PGP SIGNATURE-----
Simon Berry
> I've worked
> in is the ability to get the remote status of files "pushed" to the
> client.
A previous thread on the same issue :
http://tortoisesvn.tigris.org/servlets/BrowseList?list=users&by=thread&f
rom=583852
Andy Levy
>> A repeating request that has been made in the last 3 companies that
>> I've worked
>> in is the ability to get the remote status of files "pushed" to the
>> client.
>
> A previous thread on the same issue :
>
> http://tortoisesvn.tigris.org/servlets/BrowseList?list=users&by=thread&f
> rom=583852
One could always use CommitMonitor to keep tabs on when updates are
made in the repository. http://tools.tortoisesvn.net/CommitMonitor
However, setting the polling interval too short, or having a large
number of people running it, could potentially put undue load on your
SVN server.
Gal Aviel
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.
(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.
(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. :)
Just my 2 cents..
Gal.
Dave Lawrence
> 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
complaints...
> (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!
Fisher, John
It seems that the only appropriate action a user would take if they saw
a "needs update" would be to update. Wouldn't it be simpler, safer, and
maybe even more efficient to habitually do an update just before a
commit? That way, they've performed the action the status would suggest
they take, without waiting or polling or looking to see if they needed
to do it.
Just a few more cents... :)
John
Stefan Küng
> 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.
Your assumption is incorrect: the performance of public SVN servers
would suffer greatly! Why do you think we have the svnrobots.txt file in
the CommitMonitor?
http://tools.tortoisesvn.net/svnrobots
Yes, that was implemented before we went public. But I had several
admins already asking for that feature (they haven't seen that page
before) because their servers were under way too much stress, and some
even went down completely.
> (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.
Every two seconds? Do you know how long it takes for a server to answer
one such request?
What you're suggesting would bring most servers down.
> (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.
I've rarely seen an svn server which was hosted alone, i.e., withoug the
server being used for other stuff too.
Stefan
steven higgan
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.(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.
then make it a property on the repository that the client checks to determine whether it is allowed to crawl the repository.
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 complaints...
no that would be stupid.
the 'server cache' would run in the background, hitting the repository every x minutes.
its not as if svnserve | apache run like dogs when they are being bombarded with read requests.
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.(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. :)
the same can be said about the modified overlays, you only know the state of your WC when you do a check-for-modifications or similar operation that ignores any state and crawls the wc.
just my 2c
Simon Large
The tools are already there. You have the CfM dialog. You have commit
emails. You have Stefan's CommitMonitor program. The only way it could
be any more integrated is if the overlays reflect the local and remote
status.
That sounds great, but think about it more carefully. Now how many
combinations of local status and remote status can you come up with?
How many different icons can you easily distinguish? And given that
Windows only allows about 12 overlays in total for all applications,
how is that going to work? And what about remote file renames? Remote
file adds? You may not even have a local file to pin the overlay onto,
so you only get half a story.
TortoiseSVN has to operate within the boundaries of the features
Subversion offers, and the restrictions placed on it by being a shell
extension. What you are asking for does not fit well with either of
these constraints.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
Andy Levy
> comments inline
>
>>> (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.
>
> then make it a property on the repository that the client checks to
> determine whether it is allowed to crawl the repository.
CommitMonitor already supports this. I don't understand why
CommitMonitor isn't satisfactory for the usage described.
Gal Aviel
Thanks for the great discussion, many good points raised ..
Some thoughts:
(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.
(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).
(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.
(4) About the 2 seconds polling interval .. it was just an exaggeration
in order to make the point that you don't need TSVN in order to kill the server.
(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.
(6) If we agree that this feature should be enabled, and that it is
valuable to customers (and I think it is), then we have to make it work.
Let's not mix the implementation details/challanges, which are up
to us to sort out.
Or in short, where there is a will there is a way..
Simon Berry
well join in ....
> That sounds great, but think about it more carefully. Now how many
> combinations of local status and remote status can you come up with?
> How many different icons can you easily distinguish? And given that
> Windows only allows about 12 overlays in total for all applications,
> how is that going to work? And what about remote file renames? Remote
> file adds? You may not even have a local file to pin the overlay onto,
> so you only get half a story.
As an idea, what about changing the folder icons (coding example at
http://www.codeproject.com/KB/files/foldericonsincsharp.aspx) to reflect
that the parent folder needs updating rather than individual files. A
red folder could represent 'out of date', a green folder 'up to date',
etc
I also think you could add a timeout setting, e.g. 24 hours, where if
the client was unable to contact the server (or if it was a 'push'
system, the client has not heard from the server) for this period, the
status is shown as 'stale' or 'unknown'.
> TortoiseSVN has to operate within the boundaries of the features
> Subversion offers, and the restrictions placed on it by being a shell
> extension. What you are asking for does not fit well with either of
> these constraints.
Judging by the intensity of discussion each time this topic is raised,
it seems that this 'feature request' is a genuine need of the community.
Maybe it needs to be added to the development path ? Any technical
stumbling block *can* be overcome - that is the essence of engineering
and development.
Andy Levy
> (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.
> (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.
> (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?
> (4) About the 2 seconds polling interval .. it was just an exaggeration
> in order to make the point that you don't need TSVN in order to kill the server.
No, but this sort of feature sure would make it easier.
> (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. Since it's not a "common" piece of software, an hour or
two of training and a user guide/manual with instructions for basic
daily tasks would go a long way. 90% of the time, users will not be
doing complex merges, conflict resolution (assuming you've got a sane
policy for svn:needs-lock), etc. They'll be doing update, commit, add,
delete and lock.
Aviel,
> > (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.
Stefan Küng
>>> (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.
Andy Levy
>> > (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.
Evolve or die. I don't think asking someone to learn something as
simple as an RSS reader (you can even install it on their workstation
& subscribe for them, instead of asking them to do it themselves) is
too onerous a task. Or, as I suggested above, use email to publish the
updates instead of RSS.
Sam Barnett-Cormack
> On Wed, Oct 15, 2008 at 05:48, Aviel, Gal <gala...@yahoo.com> wrote:
>>> 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.
>
> Evolve or die. I don't think asking someone to learn something as
> simple as an RSS reader (you can even install it on their workstation
> & subscribe for them, instead of asking them to do it themselves) is
> too onerous a task. Or, as I suggested above, use email to publish the
> updates instead of RSS.
It should also be noticed that the email model is *incredibly* common
among development groups.
Sam
Boris
I had recently posted a question concerning the possibility to force an update of the local overly icons according a current repository file status. This would give an user a much better "visual" feedback which files should be updated.
see my thread: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2437477
Since you have posted a similar thread quite some time ago I would be interested to know if you found some workaround.
Best regards,
Boris
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2440054
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Andy Levy
> Hi Aviel,
>
> I had recently posted a question concerning the possibility to force an update of the local overly icons according a current repository file status. This would give an user a much better "visual" feedback which files should be updated.
> see my thread: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2437477
>
> Since you have posted a similar thread quite some time ago I would be interested to know if you found some workaround.
You're replying to a thread which is over 18 months old (from original
post). The OP might not even be on the mailing list anymore.
Please quote what you're replying to, context is very helpful, and
without quoting that is lost.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2440055