Determining base revision of transaction in pre-commit

Question

I am writing a pre-commit hook where I would like to enforce some rule based on the content of a file before the transaction. Therefore, when a transaction begins, I would like to svnlook cat the contents of any file marked "U", "UU", or "D" without the pending changes. Is it safe for me to take the provided transaction identifier (second argument to pre-commit) and strip off the dash and any characters that follow it and consider that the "base revision"? Is there a better way to get at this information?

Answer 1

The direct answer is no. The transaction number could be anything. However, svnlook youngest <repos> will return the last revision which should be what you're looking for.

Be careful with pre-commit hooks:

• Make sure that you're not doing something that will take a long time. Developers have to wait for a pre-commit hook to complete, and if you take 7 to 10 seconds processing something, developers get very frustrated.
• You cannot (and should not) change the data being committed. If it matches what you want, allow the commit. If it doesn't, don't allow the commit.
• Make sure you aren't going to stop what could be legitimate activity. For example, some sites use pre-commit hooks to prevent someone from committing a change unless they put a ticket in the commit message, and that commit message is a ticket assigned to that developer, and that ticket is in the open state. Can you imagine the hilarity that ensues when a developer can't commit a change because a ticket is assigned to someone else, and that the only person who can change the assignment is off for the week?

There are times when it's best to use a continuous integration server to verify the commit rather than a pre-commit or post-commit hook. For example, allow a developer to commit a file, but if the developer isn't in the right group, maybe email the development lead.

There's a 90% chance that the developer is probably doing the right thing. That development lead probably already knows about the issue. And, if there is an issue, you can revert the change.

Answer 2

The base revision is undecided until the revision is committed. If another change doesn't change the same nodes it can be committed while your commit is in process. Only the final part of the commit is exclusive.

Answer 3

And add 1 to youngest. e.g.:

the_revision=$(svnlook youngest ${REPOS})
((the_revision++))