VisualSVN commit-hook add revision to a file in the repo

Question

We have a PHP Project under SVN control(VisualSVN).

Somehow, i need to update a file in the repo with the current revision number. So that when the main site gets updated/checkout we can show the svn build number (this part is not the issue).

is it possible with a pre/post-commit-hook to do this?

Answer 1

Sounds like you need a build solution, rather than a pre-commit hook. Using a build system like Apache Ant, you could grab the latest revision number from the repository when preparing your solution for the live environment.

Edit: To actually answer your question "is it possible with a pre/post-commit-hook to do this?" yes it is technically possible but as already suggested, it should be avoided.

Answer 2

pre and post-commit-hooks behave differently (see the documentation in the SVN red book about the hooks and especially the part about implementing the hooks):

• pre-commit: Check if the commit is allowed. So the pre-commit hook is not able at all to change anything inside the commit.
• post-commit: Notifies about a successful commit.

So no mention of the chance to change anything. Instead, there is a paragraph in the section "implementing the hooks":

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.

So I would say, it is not possible or at least recommended to do that.

Answer 3

While mliebelt quoted the right text, he made bad conclusion. Even twice:

• It have to be done in post-commit hook
• It's impossible to do in hook

Second statement

If post-commit hook will rewrite file not included in this commit, it will be perfectly valid operation, which broke nothing.

First statement

This solution is clearly bad for a lot of reasons:

• you include in repository (in order to reference later on it) data, which is depend from overall repository data-changes, but: every change of data in this file change also state of repository data. Classical vicious circle
• you increase amount of required revisions twice: after each "data-revision" you have to perform "tracking-revision"
• you want VCS was engaged to other's problems, more applicable to build-deploy tools, for VCS having this data is enough

Repository (or Working Copy of) per se have information about last revision in it (svn info, svnversion, svn log -r HEAD), storing it inside data violates Occam's Raroz. You have only extract data, when you "publish" data for using outside repository.

Which tools and how to use is heavy-dependent from: deploy workflow, OS (you haven't gawk-grep-sed on ordinary Win-box), just some hints:

• SubWCRev (Win-only) from TortoiseSVN can inspect Working Copies and process template-files by replacing special SubWCRev's keywords by actual values. SubWCRev have sister's projects for Linux-world. Using these tools assumes storing template-file somewhere (inside or outside repo) and saving processed result inside prepared to usage project-tree
• svnversion and svnlook can be used in any OS (for WC-path and repository-path accordingly)

And at last

• You can use Subversion keywords for storing revision number inside repo, just don't forget, that $Revision$, used inside file, reflects revision of last changes in this file and have predefined format after expansion

Answer 4

What about requiring developers to update the file themselves and then using a pre-commit script to refuse commits where the update is incorrect? Perhaps the insertion of a revision number is a responsibility better incorporated into one's editor or build process / deploy scripts.