Thanks for posting on this topic. We've seen this reported a few times where Get All Changes triggers a Check In; and, so far, each reported instance involved users on an internal SVN setup. Albeit we haven't heard back from anyone with regard to what was unique about their setup that might've caused the problem. Nonetheless, our primary recommendation would be to make sure that the SVN server is a plain vanilla setup with no special hook scripts added, etc. Ensuring there aren't restrictive permissions impeding users' access would also be a helpful area to check.
One point of comparison that could shed more light on this is to try hosting the existing team project or a new team project on Axure Share (share.axure.com), and test the Get All Changes performance. Once you create a Shared Workspace in your Axure Share account, you'd be able to create a team project pointing to that location. Here's a walkthrough if needed:
Creating and Using Team Projects
Other systematic behaviors to look out for in your environment are, for example, whether the error affects each user the same across the board or even if the error affects all/new team projects located at that specific SVN location. Hopefully this can help narrow down where the problem is stemming from (e.g. whether it's attributed to permissions or something specific to the user or machine, other influencing software, etc.).