I can do this, but a quick googling didn't turn up any specifics on what the change should be.
OK, I have started this; I need to go out for a little bit, but can do some more later today. I have some questions, though, which I thought I'd float while I was away.
First, this page from the SVN book is the basic reference for keywords: http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.3.4
Starting with just src/test, since I'm still figuring some things out, I replaced all of the triple-keyword lines in the header blocks with a single $Id$ keyword, which has worked perfectly.
I wasn't sure if we had any consensus on what to do with the @version javadoc tags which appear in some places. Those tags conventionally include two keywords, $Revision$ and $Date$. These are both valid abbreviations of two of the five standard SVN keywords. However, $Date$ is being handled correctly, yet $Revision$ is not.
It turns out that one must actively enable each specific keyword to be replaced, using the "svn propset svn:keywords" command. However, I've tried doing this a few different ways (just in the struts/trunk/src/test/org/apache/struts/action directory, to further limit the side effects of my futzing), and none of them seem to work.
svn propset svn:keywords "author date id revision" *.java svn propset svn:keywords "author date id Revision" *.java
I maintained 'author', 'date', and 'id' which were already enabled, and tried to add revision. However, a few commits to TestActionMessage.java after each of those changes do not seem to result in any keyword expansion.
So, now that I've found the above page in the SVN book, I understand more about SVN keywords. When I get back, I'll continue changing the Header/Revision/Date triple lines to $Id$ -- that's easy and worked fine in the test source. Then I can look for the presence of other keywords and try to map them against what SVN supports, and also try to get a better handle on how to use 'svn propset svn:keywords' so that the Revision keyword actually works. That is, unless people want to change the way we use the @version javadoc tag to have some non-keyword content, or to use $Id$ which already works.
There's some other interesting things (which I don't completely understand yet) on that page about using properties to store metadata like licensing information. At first I thought we might be able to have a custom keyword that would inline the Apache license in all the source files; now I'm not so sure that's how it works, but it is worth a closer look.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place."
- Carlos Santana
