SVN 1.7, single working copy and multiple clients

Question

I have a workflow which worked fine in Subversion 1.6 but no longer does in 1.7.

My code lives in a Linux virtual machine which is on my laptop (a Mac). To edit the code, I mount the directory via Samba onto the host machine and use Eclipse with Subclipse.

With SVN 1.6, I could perform an 'svn switch' on the Linux command line and Eclipse would see the change after refreshing the project.

With SVN 1.7, this is no longer the case. After svn switch, Eclipse still thinks it is using the old branch even after a manual refresh. This is not just a visual issue, attempting to check in code sends it to the old (wrong) branch.

Why is this happening and is there a solution?

Answer 1

Sharing working copies between OSes and/or over network shares has never been a recommended or supported configuration. It may have appeared to work with 1.6, but there have always been warnings that it may work less well over time.

This has become more and more true as the working copy format has become more reliant upon SQLite instead of plain files.

Solution: Don't do this. Keep your working copy local to your client.

Answer 2

Commit itself is done via the Subversion API and you do not tell the API where to "send it". Internally, the API decides based on what it reads from the working copy metadata. So to be honest, this scenario seems far-fetched and unlikely. Did you actually try to commit, or are you going by what the UI says?

There are working copy layouts with SVN 1.7 where changes done outside of Eclipse will not show up inside Eclipse. We added an explicit option (Team > Cleanup/Refresh) to deal with those scenarios. This will bypass Eclipse's triggers which normally cause refresh and force us to go read the SVN metadata.

In older SVN releases, because the working copy metadata lived in every folder, a normal Eclipse resource refresh would always be triggered on any metadata updates.