2
votes

Server side hook scripts
Set up svnperms pre-commit hook
Use the commit message in a CVS pre-commit hook

I am in the process of refactoring a project by extracting several libraries from it. The libraries are moved to different repositories and are checked out via svn:external.

The problem is that commits to the central repository can't any longer explain the state of the system at the time of the commit. Initially, I am solving this problem by appending a line to each commit Tested with libA:revXXXX, libB:revYYYY, libZ:revZZZZ. by hand. Naturally, this will be unacceptable once my colleagues join in on the project, plus the libraries start being used on new projects.

What is the correct way to automate this i.e. on each commit, check latest version of trunk on all svn:extern dependencies and append that information to the commit message?

1

1 Answers

2
votes

You should NOT do this in a pre-commit hook, if it is even possible. The SVN book says:

While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors, shortcomings, or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As a bonus, your users will learn the value of careful, compliance-minded work habits.

If you don't want to include your commit comment by hand, you could always write a script that wraps svn commit and make everyone use it.

But...why do you need this in your commit message at all? You're using svn:externals, which when used properly, will already document the versions used. You are using them properly, with explicit revisions, aren't you?