1

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?

tuckermi
  • 839
  • 6
  • 17

3 Answers3

2

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.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • At first blush this seems like it introduces the possibility of a race condition. If 'youngest' changes while a transaction is in-flight, will svn appropriately determine that the transaction is out-of-date and reject? – tuckermi Jan 23 '12 at 22:27
  • If you look at the structure of the Subversion repository, it looks that Subversion's commit process only handles one commit at a time may be done. Each revision is a diff of the previous revision, so until the previous revision has been committed, you can't commit the next one. This is especially true that the repository and not the files are revisioned. It shouldn't be a problem grabbing `svnlook youngest`. – David W. Jan 24 '12 at 18:25
  • This answer seems to be a little different than what Bert wrote, though in practice it shouldn't be an issue for me as looking at the youngest revision does seem to be guaranteed to give me content that matches the base revision that I am changing. I am interested in seeing a modified file's contents as-of before the change. Thanks. – tuckermi Jan 26 '12 at 23:20
0

And add 1 to youngest. e.g.: 

the_revision=$(svnlook youngest ${REPOS})
((the_revision++))
Machavity
  • 30,841
  • 27
  • 92
  • 100
user3684593
  • 1
0

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.

Bert Huijben
  • 19,525
  • 4
  • 57
  • 73