Subversion: Add revision data to code file on commit

Question

Is there an easy way to, on commit of a file, automatically insert information into the code file itself (like author, commit comment, commit date, etc)? I would want this information appended to a block at the top of each committed file. Essentially the entire revision history should be documented in each code file...

I see there is a way to use subversion properties to achieve something similar, but I don't see how to get the actual commit comment into the file, and also I don't see how to keep a running log that has the entire revision history as opposed to just the last commit information.

I don't personally think this is a good idea as the code file should just have code in it, but unfortunately this is a requirement for my current project.

Answer 1

Subversion supports various keywords like $Id$ , $Author$ , $Revision$ and so on. To use those you need to set the svn:keywords property accordingly. However, you can't insert the commit comment like $Log$ does. See the subversion FAQ for the reasons about this, and I can only agree with the reasons given there. Putting the commit comments into the file is simply broken by design, and any such comment is wrong the moment you can't check it against the repository.

Other version control systems also don't support this, and most of them with a similar reasoning (for example, git ).

Please don't argue with something like that being a "requirement for the project". If released code has to include a change history you can add this history when creating the release with some helper script rather easily. At least, subversion simply doesn't support it. And I would strongly discourage trying to achive this with a pre-commit hook. Commit hooks should never change the data that gets committed.

Answer 2

I know it's not the answer you are looking for, but I'd try to talk them out of doing that.

The best bet would be to use keyword substitutions, but SVN does not provide a $Log$ keyword for good reasons (see http://subversion.tigris.org/faq.html#log-in-source ), which is the same reason I'd use to argue against having the log in the code.

Answer 3

I'd suggest using CVS instead. It has this capability built in. CVS is about 24 years old. Sounds like you documentation requirements may be from the era where version control wasn't common, so you are probably best to use a tool that was created in that era.

Answer 4

I see there is a way to use subversion properties to achieve something similar, but I don't see how to get the actual commit comment into the file, and also I don't see how to keep a running log that has the entire revision history as opposed to just the last commit information.

You don't want the commit comment in your file. Thats what svn log is for, after all.

Answer 5

Apart from it, as you say yourself, being a stupid idea, I can't think of a simple way to do this using SVN on-board methods. You would have to go through each file after checkout (or update) by script, identify a "change log" block within that file, and update that block with the output of svn log . Can be done but is going to be a lot of work, you would have to monitor every working copy for changes, and it is very resource intensive.

Other than that, a post-commit hook may be the best thing to work with, but manipulating files inside the repository outside a revision context sounds horrible, if possible at all.

Answer 6

We use $Revision: 9584 $ in some of our source files and the revision gets updated every time the revision of that particular file changes. But I am pretty sure you meant something different.

Answer 7

Here is an approach. Use a second version control tool, such as Visual Source Safe, which has a History keyword. Below I will say VSS but you could use any old tool that has a History keyword or Log keyword. Then follow a two step process. [1] check the source file into VSS. This allows you to write your comments and VSS will update the revision history in the source file itself. If convenient, you could do a multi-file check-in in one step and have the same comment inserted in all the files checked in. Alternatively, you can do the comments file by file. [2] check the resulting file, which is now updated with your latest revision comment inserted, into Subversion as you normally would.

By the way, as a matter of style, I find it more convenient to keep the revision history at the bottom of the source file, not the top. Most people read from the top and won't see the revision history at the bottom, so it won't bother them. Also, source code line numbers stay the same because when the revision history is at the bottom of the file, there is no source code beyond the revision history. This is convenient in some types of debugging where you don't want the source code line numbers to change every time you do a check-in.