views:

177

answers:

5

I am looking for a way to do the following either on pre-commit or post-commit or any other way.

Here is what I need to be working

  1. User commits the file
  2. Something runs (hook or something else)
  3. That something else from #2 should append static text to the file being committed

Based on this http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=3&dsMessageId=296576 I see that it is not recommended, but there is gotta be a way to append text to file on every commit.

Operating System: Sent Os

Reason why i need it: protect all code files by inserting legal notices

A: 

You can install a hook on the SVN server that will execute a script and can append information to the file etc.

There's a tiny bit of information here: http://svnbook.red-bean.com/en/1.4/svn.ref.reposhooks.post-commit.html

That said, why on Earth would you want to do this?

antik
this is not possible according to this"A post-commit hook is only triggered after the the commit is completed --that is, after it has already been "checked in". Such a hook would have nohope of modifying the file "being committed". The hooks which are triggered*before* a commit is finalized are start-commit (which happens too early toknow what is being changed in the commit) and pre-commit (which happensimmediately after all the changes are sent to the server, and immediatelybefore those changes are finalized into the next revision of the repository."
Chicago
+6  A: 
Harper Shelby
+7  A: 

Look at the red box at the end of this chapter of the SVN book:

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.

I subscribe to the POV that text in red boxes should be taken serious.

sbi
yeah, it is possible to notify the user that legal statement needs to be added manually and then accept the commit. Now, what if you are commiting 100 files? User will have to manually add legal notices to all files:(
Chicago
Provide them with a script to do this on their machines before they attempt to checkin again. (But then I suspect that, if you create 100 source files at once, having to add a legal notice is the least of your troubles. They have to be filled with something worthwhile to be checked in, after all!)
sbi
A: 

How about working on this another way - use a robot. It's a bit more work, but basically: accept the commit into the repository without the required legal section and trigger the robot to have a look (or have the robot look periodically).

The robot then does a checkout/update of the files it looks after, checks their policy and legal notices, automatically adds anything it needs and then checks the changes back in. This way, subversion's caches are happy and the legal notices are on all files. Developerse will pull the changes down on the next update/commit cycle just as they would any other change. You can even have the robot automatically keep the legal section up to date with the latest definition, depending how complex you want it to be.

Might even be able to make use of something like Hudson to host this in a useable framework.

Jim T
this is interesting. Tell me more. Do you have examples? Also, here is what I fear. If developer has 100 files checked-out which do not have legal notices, then robot will go and update those files with legal notices and commit. After that developer will have to solve 100 merge conflicts, is that right?
Chicago
No examples, I've not had to do anything like this before, but it wouldn't be any different to set up than a CI build, just with a script that walks over the files instead of builds them. Yes, conflicts would have to be resolved, but it would be no different or any more difficult than if you had gone through and added the legal notices yourself. SVN should be able to merge most of these changes automatically.
Jim T
+1  A: 

So far the only feasible solution is to use client-side hooks of tortoiseSVN:

http://stackoverflow.com/questions/1651120/inserting-comments-automatically-using-tortoisesvn

Unfortunately, this limits developers to use only TortoiseSVN. Using Visual Studio plugins, for example, will not work:(

If someone finds any centralized way of how to do this, please, post here.

Chicago
I just added the torotoisesvn tag as it is client specific. Perfect answer [+1] ;-)
jdehaan