I'm still learning TortoiseSVN 1.6 and so far I'm not able to setup keywords so they are updated in a file once a commit command is ran.
I have both right clicked on files/directories > Properties > New. I select svn:keywords from the drop down and then in the property value field I add $Author$ $ID$ $HeadURL$ $Revision$ and $Date$.
I also add these to the by right clicking on the desktop > settings > Subversion Config File. From here I have uncommented out enable-auto-props = yes along with adding the following two entries:
*.cfc = svn:keywords=HeadURL Revision Author Date ID
*.cfm = svn:keywords=HeadURL Revision Author Date ID
My files are basic text files with the following:
After I commit this the repository, these keywords are not updated, so I'm not sure what I'm doing wrong here.
In your text file, you only need to do this:
$Revision$
$Author$
When Subversion does a checkout, it will change them to:
$Revision: 1234$
$Author: Quimby$
No need to title your keywords first.
You must have svn:keywords set if you want Subversion to expand the keywords. You must have the value of the svn:keywords property as bare keywords separated by white space separated, AND correctly cased. It must be $Id$ and not $ID$.
In other words, you're svn:keywords property should be set to:
Revision Author Date Id
and Not
$Revision$ $Author$ $Date$ $Id$
Also, will the end users that I'm rolling this out for will they have to edit their Subversion Config File or only worry about setting key words on files/directories in their WC?
Since svn:keywords is a property, it will be set in all working copies. Anyone who does a checkout will see the expanded keywords.
The question is what happens if someone adds in a new file, and you want svn:keywords set on those too. In Subversion versions 1.7 and before, you would have to use a pre-commit hook to fail a commit if these properties are not set to a particular value on your files.
Developers, after a few times getting their commits rejected because they don't have this property set on a file can set it in the autoprop section of their Subversion configuration. This way, when they add a new file, Subversion will automatically add in the property.
In Subversion 1.8, inheritable properties have been introduced. The two main ones are svn:autoprop and svn:global-ignores. These two properties can replace the global-ignores and autoprop section in the User's configuration. These is a way you can do this for the entire repository without worrying about the user's configuration.
However, Keywords are not that useful. They usually generate a lot more pain than light (and with $Log$, are downright evil).
What information do keywords give you? If you are inside a working copy, you can get all the information that keywords have and more by simply running a Subversion command.
Outside of a working copy, keywords usually disappear in the compile phase. Even if you embed a keyword into a string, it's only that version of that file, and doesn't tell you the rest of the file versions. A better way is to embed a version string that makes overall sense to you. For example a version number for your whole program. If you use a CI system like Jenkins, this is very easy to do. In fact, we embed Jenkins project and build number (and the working copy's revision) when we compile our code.
It might be more useful in scripts, but there it can easily deceive. Imagine a Python script that had the Revision of that Python script embedded in the file. A bug is discovered, and someone modifies the file. The embedded keyword is now misleading. Let's say a new feature needs to be added to this script. A developer looks at the revision number on the script, checks it out, adds in the feature, and then gives that new version back to the customer. Now, the original bug is back in the program.
This is why many version control systems have gotten rid of keywords, and if they do have them, they have to be turned on one at a time for each file. They can cause problems with compilation (this was especially true in SCCS where keywords were a single letter surrounded by % signs which caused a few incidents of accidental expansion), they can mislead, and in modern version control systems, aren't that necessary.
Think carefully before your strategy before embedding keywords onto all files.