Prevent checkins to SVN

My team uses SVN for our software platform, and we create tags periodically to help keep module versions straight. Best practice, as I understand it, is not to modify a tag once it has been created. However, it seems that sometimes the temptation is too great and a modification is made to one of the tags.

Is there a way t开发者_JS百科o prevent these kinds of checkins, or at least make them a complete pain so that we can discourage them automatically?

Thanks, Joe

---

Create a pre-commit hook which will reject the commit if the tag exists already. More details on implementing hooks can be found here (see the Implementing Repository Hooks section):

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html

---

Methinks you are trying to find a technical solution for a non-technical problem. You have to identify why these checkins are made before figuring out how to deal with them. If they are made with the approval of the team leadership, no amount of process would prevent them from happening in the future. If on the other hand these checkins are made by individual team members who thought they know better - well, then you get the leadership involved to solve the problem of a rogue developer.

Only after the whole team is clear on what is expected once a tag is created, you can enforce these expectations with a technical solution (if needed).

As for how to prevent checkins - seems to me that the simplest solution would be once you've created the tag to set the security on it to read-only for everybody through the path-based authorization. Note however, that the authors of the SVN Book also explicitly state the following about the path-based authorization:

Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced.