升级到TSVN 1.6.8.19260后，我有同样的问题(在资源管理器中没有图标)，但在我的情况下，在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers下根本没有TSVN条目。在我最初的安装中，我没有包括额外的图标集，因为我从来没有使用过它们(而且我从来没有在以前的任何升级中安装过它们)。

我修改了安装，添加了额外的图标集，我的图标神奇地重新出现了。

我发现，如果你先安装32位版本，它会把64位版本弄得一团糟。在重新安装windows 7时，我刚刚安装了64位版本，现在看起来工作正常。

克里斯·埃里克森说得对，给他投票吧。在我的案例中，问题是安装TFS powertools，它添加了资源管理器外壳集成，就像TSVN和TCVS一样。它增加了另外5个叠加。因为它们的前缀是Tfs*，所以它们优先于Tortoise*。我也只是把Tfs的东西加上了z_和TSVN的覆盖回来了。不过不需要重启/注销，只需杀死explorer.exe并重新启动它。

可能出现的问题和解决方案

Windows限制可用的覆盖图标的数量，参考Kris Erickson的回答。 TortoiseSVN设置不当，参考Ralph Cowling的回答。 从早期版本(1.6.10之前)更新的已知错误，请参阅这里。 TortoiseSVN并不是为所有用户安装的，尝试像下面这样用cmd安装，如果下面三个解决方案都不工作，我相信这个方法会挽救你的生命。

rem Set your own path.
set TOOL_ROOT=d:\Tools\TortoiseSVN-1.6.13.20954-win32-svn-1.6.16\tortoisesvn_1.6.16.21511
set PACKAGENAME=TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
set TOOL_INSTALLROOT="c:\Program Files (x86)\TortoiseSVN"

msiexec /i "%TOOL_ROOT%\%PACKAGENAME%" INSTALLDIR=%TOOL_INSTALLROOT% ALLUSERS=1 ARPSYSTEMCOMPONENT=1 RebootYesNo=No REBOOT=ReallySupress /qb-

set ret=%ERRORLEVEL%

rem The installer seems to return same values as MSI
rem These codes mean that the product is properly installed, even though the code is not zero.
rem 1641 ERROR_SUCCESS_REBOOT_INITIATED
rem 3010 ERROR_SUCCESS_REBOOT_REQUIRED
if %ret% EQU 1641 set ret=0
if %ret% EQU 3010 set ret=0
if %ret% GTR 0 exit %ret%

我遇到了与OP相同的问题:Win 7 (x64)， TortoiseSVN (x64)和DropBox (x86)。其他一些答案给了我所有的信息。我在这台机器上只安装过x64版本的TSVN。

以我为例，TSVN和DropBox是在我安装操作系统的同一天安装的，直到几天前，它们的覆盖工作都很好。我没有做任何改变这两个应用程序设置导致它们停止工作的事情。

下面是问题开始后我在图标覆盖注册表部分(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\ShellIconOverlayIdentifiers):

DropboxExt1 DropboxExt2 DropboxExt3 EnhancedStorageShell 离线文件 SharingPrivate TortoiseAdded TortoiseConflict TortoiseDeleted TortoiseIgnored TortoiseLocked TortoiseModified TortoiseNormal TortoiseReadOnly TortoiseUnversioned

我验证了只有对应于前11个条目的覆盖显示在资源管理器中。当我通过在其中一些条目的开头添加'z'来修改上述条目的顺序时，仍然只显示前11个覆盖(在更新的顺序下)。

有了上面的内容，我就有了解决问题所需的一切(重命名或删除条目，以便我想要工作的TSVN条目在列表上<= #11)。下面讨论为什么会突然发生这种情况。

I know that based on the overlays that worked prior to a couple of days ago, keys 1-3, 7-9, 12-13 were all <= 11 in the list (not sure if overlay #14 ever worked since I never had files w/ read-only status. #15 never worked on this machine so i know it was never in the top 11). I also assume the block of TSVN keys move up/down in unison, therefore they were bumped down either two or three places (* see below). This implies that 2-3 items were added between the DropBox & TSVN blocks. The three that are there now are added by Windows and I would assume they'd be there as soon as the OS installed.

15个覆盖的列表是否在运行时确定?似乎覆盖处理程序有时会告诉windows shell没有图标可以添加到列表中。可能是我几天前搞砸了文件共享和文件加密的一些设置，导致4-6个位置的一些项目被“激活”，并将SVN的项目推下。

最后，我删除了一些条目，并移动了一些，所以我的最终列表看起来像这样:

DropboxExt1 DropboxExt2 DropboxExt3 SharingPrivate(我想显示这个) TortoiseAdded TortoiseConflict TortoiseDeleted TortoiseModified TortoiseNormal TortoiseReadOnly TortoiseUnversioned zOffline文件(我不使用同步中心，或“脱机文件”，所以我不关心这个) zEnhancedStorageShell(不知道什么是增强存储，不认为我需要这个)

如果您最近升级了Tortoise SVN，这可能是因为版本1.7似乎需要一种新的格式来存储文件的状态——在这种情况下，您可以右键单击您的存储库的根文件夹，并使用“SVN Upgrade Working Copy”的Tortoise菜单选项。

这为我解决了问题。

干杯 马特