I installed the latest and greatest TortoiseSVN on a new PC (which happen to be for SVN 1.7), and happily upgraded my working copy when prompted. Newer is better isn’t it? After all, I didn’t like the .svn folder everywhere, which 1.7 got rid of with centralized metadata storage.
To my horror later, Netbeans wouldn’t update my workspace anymore, since the current version has no way to support 1.7 yet, other than the command line client. Fine, I installed the 1.7 CLI over my 1.6 CLI, but the Subversion features in Netbeans became sluggish and often show incorrect change flags until I manually activated Show Changes each time.
Downgrading to 1.6 was not an easy feat, I installed TortoiseSVN 1.6.16, judging by it being the latest release bound to SVN 1.6. I was lucky my SVN server is local so re-checking out my workspace was not that tough (I know some places which will take hours, and I haven’t found a “downgrade working copy” method that didn’t require a checkout).
Then Netbeans complained the working copy isn’t compatible anymore with my SVN 1.7 CLI. I cleared the SVN path setting, but couldn’t find any option to force it to revert to using the built-in bindings. Reinstalling the plugin did not help either. A half hour later I resorted to a brute force search on “subversion” in the netbeans folder and my home folder and I finally found this file:
where the option “forcedCommandline” is set to true. Changing it to false and restarting my IDE got me out of the situation and ended my fight with SVN 1.7. I still like the idea of the new working copy, so hopefully a new NB SVN plugin will be released soon.