On 8/4/2011 5:33 AM, Andy Levy wrote:
> On Wed, Aug 3, 2011 at 22:36, Kevin Radke<kmradke_at_gmail.com> wrote:
>> On 8/3/2011 3:08 PM, Andy Levy wrote:
>>> On Wed, Aug 3, 2011 at 15:34, Todd Nelson<toddyboy82577_at_gmail.com> wrote:
>>>> If a user installs TortoiseSVN 1.7, any working copies that have not
>>>> been upgraded are difficult to find because there are no icon overlays
>>>> displayed on the working copy. It would be beneficial to the users to
>>>> put an icon overlay letting the user know they have not updated the
>>>> working copy. You could reuse the same icon for modified or
>>>> conflicted files since the limitation on the number of icon overlays
>>>> still exists in Windows 7.
>>> This was *just* addressed earlier today.
>> I don't really buy the potential performance impact argument. TortoiseSVN
>> already knows it is an old working copy because it adds an "upgrade" entry
>> to the right click menu... I found myself manually right clicking on
>> multiple folders to remember where all my working copies were located.
>> Without the visual hints of an icon, I'm sure I missed a few too!
> Stefan is usually correct about his code.
> That discussion is continuing, please follow it.
Yes, I am following this. Stefan is a VERY reasonable guy and I believe
TortoiseSVN is one of the top reasons that Subversion has been so
successful. I have also seen him change his mind in some cases, such as
shipping the command line executables in the installer. I believe
decisions like that have made a great application even better.
I don't have a build environment setup for Tortoise, but a quick look at
the code shows that the BlockPath code is fairly isolated. There is
already precedence in showing an overlay icon for block paths. (See the
show excluded folders as normal settings.) For example, in
CachedDirectory.cpp svn_client_status5 already returns a
SVN_ERR_WC_UPGRADE_REQUIRED value in this case, but isn't treated
special. These paths should still be treated as blocked since you do
not want to continue to crawl them, but icon overlays do not need to be
mutually exclusive of blocked paths.
I'm not faulting Stefan for focusing efforts in other areas. I'm only
faulting myself for not having enough time complete a patch before the
>>>> A utility to search a given disk or path to find all working copies to
>>>> upgrade at once would also be useful. We have developers with a large
>>>> number of working copies and unfortunately, they aren't all in the
>>>> same parent directory. Instead of having to manually search for
>>>> working copies, this utility would find them all and upgrade them at
>>> How do you handle errors encountered in performing the upgrade?
>>> Why can't the developers upgrade their WCs when they're ready?
>>> Let's say I'm a split Java& .NET developer. I've updated TortoiseSVN
>>> and AnkhSVN, but I haven't upgraded Subclipse (Subversion plugin for
>>> Eclipse) yet. Automatically upgrading *all* of my WCs will immediately
>>> break my Java project WCs, at least for usage inside my IDE.
>> Nobody is saying you have to upgrade all working copies. This would simply
>> just search the specified locations and say "hey, I found these working
>> copies, select the ones you want to upgrade..."
> The OP pretty much asked for upgrading all existing WCs.
I didn't read Todd's request quite so literally. (Probably because we
discussed this off list before he posted.) I would expect an
implementation to allow selection of the ones found.
> How do you handle this for unattended/silent installs? Maintain the
> current behavior (no upgrades) or silently upgrade them all?
Either option would work, but the best option would be to add an option
for silent installs to select a way, but defaulting to the current
behavior. Choice is the benefit here. We can't make one behavior
perfect for every scenario, but allowing the user/admin choose the
behavior they want/need is the key...
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-08-05 05:09:27 CEST