I've been having issues with TortoiseSVN 1.9 and IntelliJ 14 for a while, which disappeared after downgrading Tortoise to 1.8 (thank you, Lazy Badger for the answer).
Now whenever I right-click a folder I get a popup titled "CrashHandler initialization error" and the following message: "C:\Program Files\TortoiseSVN\bin\SendRpt.exe not found". It's a native crash handler of Tortoise, but its exe is not in the bin folder for some reason.
Tortoise works, it's not a blocking issue, but a very annoying one.
Wanted to attach a screenshot, but don't have enough reputation. :/
#Olga VDB's answer works. But for anyone who doesn't want to reboot their PC - just killing/re-starting Explorer.exe works too.
Actually just needed to reboot PC. Not deleting the question, maybe it will help someone else.
Just go to Control Panel\Programs\Programs and Features. Click on TortoiseSVN and do "Repair". Its will get it resolved this issue.
Control Panel > Programs, Uninstall the prior version of Tortoise SVN.
Reboot.
Go to the folder where SVN had been installed and, if it is not already empty, manually delete any remaining files. ( If the DLL files in the bin folder are locked and you cannot delete them, rename them individually, e.g. from .DLL to .DLL.off. After the next reboot cycle, you will find that the files can be deleted. )
Then install the new version of Tortoise SVN.
Although the above answers seem quicker, if you have already tried them and you are still getting endless crash handler error messages every time you right-click anything in Windows File Explorer, go through this complete cycle to clear up the problem.
This worked for me on Windows 10 Pro 64-bit "1703", going from Tortoise SVN v1.9.5 to v1.9.6.
There is an explanation about the different versions of the Tortoise SVN crash handler on the Tortoise SVN site
Related
Hopefully someone can help. Have an APP that I have been working on for awhile. Compiled it earlier, no issues, and ran a debug on an attached device.
When I came back to AndroidStudio today, was prompted for an UPDATE to studio as well as a Gradle update. Ran both updates as listed... no errors during the update.
Restarted AndroidStudio and "Run APP" once again. Went through the Gradle Build as normal... then received an error when installing to the attached device....
Session 'app': Error Installing APK
Checking the RUN, I am getting:
The APK file C:\Users\Pete's PC\AndroidStudioProjects\<myapp>\app\build\outputs\apk\app-debug.apk does not exist on disk.
Error while Installing APK
That file exists with the current build date/time.
Doing some searching, people mention CLEAN / REBUILDS in various steps, tried them all. Tried exiting AndroidStudio too. Went to the device's Developer Options and Revoked USB Debugging Authorizations... then reapproved them when prompted. Also tried SYNC.
Nothing works.
It's even more frustrating because I didn't change one line of code, one setting, or anything. It was a prompted AndroidStudio/Gradle update. Uggghhh!!!
Any other suggestions... I am dead in my tracks right now.
I do get the same problem as yours but I solved it by transferring the project file to a thumb drive. Any drive but not C drive.
It can install the apk in my phone. Hope it works.
It looks like it might be an actual bug in AndroidStudio. My "path" to where the project is stored is based off the "computer name" that was created when my copy of Windows 10 was originally setup... "Pete's PC".
So the path is....
C:\USERS\PETE'S PC\AndroidStudioProjects\myproj
It looks like the apostrophe (') in the path is throwing it off. If I move the project to ANY where where there isn't an apostrophe in the path, it compiles/installs fine... as is.
Thanks to Syaf for sort of pointing me into this direction with his "move the project to a flash drive"... that's what got me thinking and trying things.
Sadly, this is possibly a problem for alot of people because even during the Windows 10 setup, you are prompted to name the computer you can remember.... like John's PC.
I forwarded my findings to Google for review.
Peter
I've installed eclipse Mars.1 Release (4.5.1), and than i've installed spring plugin as i always do with a new linux installation (by the way i am running Manjaro Linux 15.09 fully updated with KDE) but this time i am facing a problem i have never seen before!
Everytime i go to the preferences window, the right pane won't update according to the selected option.
Ex: when i open the preferences window, if i try to drill down the "General" option, the right pane won't update, no matter what i choose in the left pane!
Can anyone help?
I had the same problem. The reason was because Eclipse didn't set up completely - there was some background tasks running (freezing actually).
Try to run Eclipse with another JRE version. I have this problem with 8u60, but everything is fine (as fine as it can be with Eclipse) when I use 8u45.
Off topic - I strongly recommend everyone to stop using Eclipse and go to Intellij IDEA. Your life will become much more happy.
UPD I faced that problem again with the new workspace, so maybe this isn't about JRE version. Try to wait a few minutes, reopen workspace again, this worked out for me.
I have a medium-sized solution with 99 projects that has recently started behaving weirdly:
1) If I try to rename a file through the solution explorer, VS will seemingly hang, but after a long time (10+ minutes) it will complete the rename operation.
2) I also noticed today that switching to between Debug and Release mode seems to freeze VS as well. So far I haven't let it run long enough to see if that actually completes.
I've tried both Visual Studio 2012 and 2013, and both exhibit the same problem, so that seems to indicate the problem might not be with Visual Studio. I've tried to check in the event log if there's anything there, but nothing jumped out on me. I've also rebooted and run checkdisk, but it didn't find anything wrong.
Running Windows 7 Professional on a fairly high-specced laptop with 8GB RAM and a new SSD
Update: apparently if I have renamed a file once, I can keep renaming it (and other files in the solution) immediately. When I restart VS, it's slow again.
Update2: I left the computer running overnight to try to switch from Debug to Release, and it managed to do so in the 14ish hours between me leaving work and getting back here.
Visual Studio can be extremely slow in renaming files if you are using TFS with a "local" workspace as oppose to a "server" workspace, and the total number of files including different versions in the TFS repository exceeds 10,000 items.
Contrary to Microsoft's recommendation, I suggest using a server workspace instead of a local one for much better performance. There are also some other downsides to local workspaces and the only upside is being able to work while your TFS repository is down. That's not much of an upside considering if you can't connect to TFS, you probably can't connect to your LAN and there's darn little work you can do anyway in that situation.
To change to a server workspace for TFS in Visual Studio 2015,
In VS click on File --> Source Control --> Advanced --> Workspaces
In the dialog that opens, select your workspace and click Edit...
Click Advanced... (it does not matter which mapping is selected).
Under Location, select Server and then press OK.
Switching over to server may take ten minutes or more depending on the size of your repository.
Once this is done, renaming files should be nearly instantaneous.
When testing I'd made an attempt at setting up one of the projects to build on a different server, both in Debug and Release mode. I though I'd cleaned up both, but apparently I'd only done so under the Debug configuration.
Apparently meanwhile that server has decided it hates my machine, which makes my machine freeze while waiting for it.
Closing Visual Studio and manually editing the .csproj file solved the problem.
Unfortunately 99 projects is not a medium sized solution for Visual Studio but instead a very large solution. Visual Studio simply doesn't scale well to solutions of this size and you're seeing the effects of that here.
The only way to make this better is to factor out your solution into several smaller solutions.
Building on #Daniel Barbalace's answer, my issue indeed had to do with TFS, but I could not switch to server workspaces. What I ended up doing was removing the mappings to any branches or projects that I am not working on at the moment. There is no magic number but once I seemed to get under 50,000 files (globally for the TFS folder) renaming suddenly went down from 2+ minutes to 3-5 seconds.
In my case "git" cause that,i have a bunch of html files in my commics project,so,when i removed .git folder i have again fast renaming files.
I had the same issue. Renaming one file would take a decade. I found a solution however. When I first check out for edit, renaming becomes very fast again.
I've recently installed a fresh win8 copy. After installing tortoiseSVN, it does recognize the folders as being under version control (the menu items are there), but no overlays on the icons.
I Checked the registry settings as described here: TortoiseSVN icons not showing up under Windows 7
But the first 9 entries are all for tortoiseSVN and there are 4 others, so no problems there.
What could be the problem?
Go to regedit. Find HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers.
Add space before folders, example: "1TortoiseNormal" -> " 1TortoiseNormal".
Restart computer.
Works for me.
Go to TortoiseSVN > settings > Icon Overlays > Status cache changed from default to shell.
If the drive A, B or network is used check that drivew
Please try this :
Sometimes you just have to restart Windows (if not already done).
You could also have to do a "Cleanup" (right click, Tortoise SVN shell entry) of your working copy, and to check "Refresh shell overlays" in the window.
Also, please review "Icon overlays" tab of Tortoise settings (right click, Tortoise SVN shell entry, Settings) settings of your tortoise SVN, especially if your working copy is (for example) on amovible or network drive.
In my case, the problem was that I was working on a network drive. By default, Tortoise doesn't show icons on network drives.
To enable the icons on other types of drive, right-click in Windows Explorer and go to:
TortoiseSVN --> Icon Overlays --> Drive Types
This may also solve the problem in other cases, where other drives are in use and not showing icons for you.
you have to do an svn actualization (in my case a fully checkout). just restart the explorer (or computer) after configure the registry did not show the overlay icons in my case
Modifying the registry, tsvn clean up etc did not help anything.
Solved it by killing the process 'TortoiseSVN status cache' in task manager. Icons reappeared one by one after that.
In TSVN settings I've set the Status Cache to default (was None initially), but not sure this had anything to do with it. Also restarted explorer.exe to be sure.
I had an older/non-compatible version (1.6) of TSVN installed before updating to latest (1.8.8). This could have been part of the problem.
I have been experiencing a problem with tortoise .
when i checked out the code the tortoise icons usually green or red on the folders are not coming.Any solution???
Thanks in advance.
1 - Check If Your TortoiseSVN Settings are Correct
Right-Click in an SVN Folder >> TortoiseSVN >> Settings
Select Icon Overlays:
1. Status Cache to Default
2. Drive Types: (SELECT) Network Drive, Fixed Drive
2 - Find out if there are too many Icon Sets installed in Windows
Window allows up to 11 IconSets, if other programs like DropBox are installed they will hijack those spots
Since we are working in the registry, be careful not to edit things, unless you are sure!
Run regedit
Navigate to: HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/WINDOWS/EXPLORER/ShellIconOverlayIdentifiers
If there are more than 11 Folders, then you have too many IconSets
:: In my case, it was because of DropBox - the folder names were ("DropboxExt1","DropboxExt2") and my Tortoise was named (1TortoiseNormal,2TortoiseModified)--The problem is that Windows reads this and enables them based on alpha numeric order ('"' comes before '1' in the alphanumeric stack)
SOLUTION : If you had the same problem as me, you can simply rename the Dropbox registry listings. I renamed my Dropbox listings from('"DropboxExt1"') to ('X"DropboxExt1"'), just adding an 'X' to the beginning of the registry. >>Restart your machine to see the registry listing take effect.
Try also to repair the installation, if you upgraded from 1.6.8 or 1.6.9. Just re-launch the TortoisSVN installer and choose "Repair". There are known problems with overlay icons and TortoiseSVN upgrades (see this blog post).
If you have checked out your code onto a network, or removable drive, you need to set some preferences to see the icons.
Please refer the following link
http://tortoisesvn.net/node/97. I have also experienced simillar problem and the icon usually starts appearing after two or three reboots.
Also refer the following links
http://gavtaylor.co.uk/blog/missing-tortoise-svn-shell-icon-overlays
TortoiseSVN icons not showing up under Windows 7
You can go to TortoiseSVN>Settings>Icon Overlays>Status Cache.
If default is selected then change from default to shell. If shell is selected then change it from shell to default. it should fix it.
Maybe it depends on your platform? You need to install 64-bit TortoiseSVN if you want the TortoiseSVN Overlay icons in Windows Explorer, because Windows Explorer is 64-bit on Windows 64-bit.
see http://tortoisesvn.net/faq.html#nomenus
Make sure you have installed the x64 version of TortoiseSVN if you're
using XP or Vista 64-bit. Since the explorer on those OS versions is a
64-bit application, it can not load the 32-bit version of TortoiseSVN.
You can still keep the 32-bit version of TortoiseSVN installed on
those OS versions though: it will show up in the 32-bit applications
file-open/save dialogs of those applications.
In the recent versions of the TortoiseSVN, old _svn folders are deprecated. it's better to rename them to .svn.
attrib -h _svn
rename _svn .svn
attrib +h .svn