Prevent user from 'replace' during commit with Subclipse or in (apache) SVN

Question

Working in a multi-developer environment with SVN I sometimes run into the problem that a developer (by accident) replaces a file by a copy/paste of the file. This sometimes goes unnoticed as a diff just works before the commit in the synchonisation view of subclipse.

In SVN this ends up as a commit with a '(file) replace' (instead of modify). This replace makes it harder to see the history of the file, as SVN thinks it's a new file instead of a modified file.

I would like to prevent that the developers are able to commit replaces. Or at least make them very aware that they actually are trying to do that.

I can split my question into multiple layers, depending on what is possible:

1. Would there be a way to prevent a commit with a 'replace' inside it from being allowed, without special access (server side in apache SVN)?
2. Would there be a way to prevent a commit with a 'replace' inside it? (inside subclipse)
3. (in case 1 and 2 are not possible) Would there be a way to make the developer aware he is going to do a 'replace' in his commit? (inside subclipse)

Many thanks.

Answer 1

Are they using an updated version of Subclipse? Most of the reasons for this are caused by Eclipse and the way it drives the Team API. In some situations when you copy and paste it tells the Team API that you deleted the file, which causes Subclipse to run svn delete. The new file is then svn add which amounts to a Replace.

Newer versions of Subclipse detect this situations and do a little dance of steps to turn it back into a modification. Current version of Subclipse is 1.10.1, that version or the most recent 1.8.x version should have these changes in them.

1. You can write a pre-commit hook on the server to look at the changes in the commit and reject the commit if it contains a Replace. Take a look at the svnperms.py example hook script that Subversion provides. If it does not already do this, it would show you how to do it.

2. Cannot stop it from happening, but a newer Subclipse version might make it less common.

3. The decorators might look different and the SVN properties would show status replaced, but nothing would make the user look at these things. #2 would be the better option.