Word Aligned

I agree that keywords are a bad idea most of the time, but your last two points aren't actually true, with respect to how subversion works. Keyword substitution doesn't modify the file on checkin, it modifies only the working file upon checkout. In other words, the file stored in the repository is 'contracted' (no keywords), something like $Id:$. Only when you checkout the file to a working copy, does the *working* verson of the file expand to $Id: blah blah$. When you run 'svn diff', the working file is contracted and compared against the contracted text-base; the same contraction happens when you 'svn commit'. So it turns out that you don't see spurious diffs either in the commit diffs or when comparing two trees against each other. I still hate keywords. :-)

Thanks for the correction Ben. For point 2), I guess I should have said that the modification -- and hence the rebuild -- happens when you (or others) update their working copies.

Point 3) does hold if you're using the basic Unix diff and patch tools rather than svn diff and svn merge. So the message is: prefer to use svn diff and svn merge!

In general I agree... but I have come across some legitimate usage models for keyword expansion (if ever they could exist ;)

This is an actual case from a development shop with ~1,000 developers. They develop core software that is delivered to customers as source. Every so often, they release a new version of the source code to the same customers. The customers then take these "vendor drops" and customize them internally. Of course, they use their own VCS tool to manage their changes. Over time, the customers will hack/slash/handmerge multiple vendor releases into a "working copy." Not ideal and not recommended but the fact remains... the original vendor deals with frequent support calls and is unable to get an answer to "what version are you using?"

Their solution is to embed keyword substituted variables into each source code file... so regardless of the source-jumble that results on a customer site, the customer can reference $Id$, $Log$, $Author$, etc and the vendor can use that to trace back to the original version of code.

I don't like using the built-in VCS mechanism for keyword expansion per your aforementioned reasons. Rather, I prefer to do a post-release, pre-deployment keyword filter on source code being packaged. This can optionally be version controlled locally as well, but no need to have the keywords embedded in the code from the beginning.

David -- thanks for the note. What you describe is on a scale way beyond my experience. Here are some more thoughts spawned by your comment.

Although you make some valid points against keyword substitution, there are occasions when it is extremely useful. We use SVN for controlling changes to config files for the servers we maintain. Using the Id field allows us to track the changes that have been made on the files and the versions/admin who made the changes.

We could use RCS, on each server, but use SVN for a more centralised approach to manage the ~100 servers.

Most of the files we are using are config text files or simple shell scripts. We could manually add the history log, but using SVN and the keyword substitution gets around this, and allows us to see at once on a server which version we are dealing with, even if there is no direct SVN access.

Thanks for the feedback Joel -- though I'm not quite sure I understand it! Are you saying that your servers are all running independently, and that each runs its own flavour of software? How many SVN repositories do you have and where are they located?

If you need to know who changed what when, then the Id field is only the tip of the iceberg of information available in the version control system (admittedly, the tip is often the interesting bit), so surely what you really need is SVN access?

In any case, I take your point: keyword substitution is helping you out.