tags:

views:

311

answers:

6

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.

+3  A: 

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.

pgb
These are code files which will never have to be merged. The other developers want to see the changelog in the file while they are working on it. I tried explaining they can see the changelog very easily within 2 clicks but the answer was "Well, that's 2 clicks too many!"
Mike Gates
+1  A: 

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.

Sofahamster
I know its a bad idea but as I mentioned in my question, I have to do it!
Mike Gates
A: 

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.

brianegge
A: 

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.

Pekka
A: 

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.

Willi
+1  A: 

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 disencourage trying to achive this with a pre-commit hook. Commit hooks should never change the data that gets committed.

bluebrother