2

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?

Community
  • 1
  • 1
Vorac
  • 8,726
  • 11
  • 58
  • 101

1 Answers1

2

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?

Ben
  • 8,725
  • 1
  • 30
  • 48
  • It shows how inept I am. The root folder of my project has a property `svn:externals` that contains several lines of the sort of `http://192.168.10.2/svn/main/CodeTemplates CodeTemplates`. What revisions? Those libraries are supposed to be constantly evolving. – Vorac Jan 22 '15 at 13:05
  • Change it to something like `http://192.168.10.2/svn/main/CodeTemplates@1234 CodeTemplates` to pull in the specific revision 1234 of the CodeTemplates library. Why do this? First, when you update to old versions of your project, you see the *entire* project exactly as it existed at that time, including the externals. Second, if library development is independent of the main project, you can control *when* to pull in potentially breaking changes. See the [section on externals in the svn book](http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html) for details and a big warning box. – Ben Jan 22 '15 at 16:07
  • This approach is very inconvenient as of now - because the project is like a wrapper around the library - all the development is happening inside the library - but seems to be the only sane solution. Once things stabilize, I'll apply it. (+1 and accept) – Vorac Feb 02 '15 at 12:59