views:

98

answers:

5

On a couple of projects now, I've used the SVN keywords to retrieve some information about the version of some core files. Something like this (PHP):

$revision = '$Revision: 1254 $'; // automatically updated each commit
$revision = preg_replace("/[^0-9]/", "");

echo "This file is at revision #" . $revision;

It occurred to me however, by inspecting the $URL$ keyword output, I could tell if the current file was in a tag, branch or on the trunk and apply different logic to the program, eg, increase the cache times, etc.

$svnURL = '$URL: path/to/repo/tags/1.0.1/folder/file.txt $';
if (strpos($svnURL, "/tags/") !== false) {
    echo "Tagged version!";
}

Is this veering sharply into WTF territory, or would you consider this practice to be acceptable?

+2  A: 

Mm, that's veering into WTF world as far as I'm concerned.

Better off configuring those things as environment variables in a general place in your application.

Noon Silk
+1  A: 

In my opinion, using the SVN keywords to affect program logic is a little bit obscure. I don't feel it qualifies as pathological, but it would surely require some explanatory comments.

Also, in your example, you simply echo what amounts to version information. I take it from what you wrote that you intend actually to decrease the cache time for your tagged version. As that aids debugging and is specific to your internal practices, I can see why you might want to do this.

Heath Hunnicutt
actually, I would have *increased* caching on the tagged version, since hopefully it would have already been tested, and it increases performance. thanks for the comments.
nickf
Oh. In that case my opinion is changed and I think it is a really bad idea. Suppose you find out that increasing the cache value causes some problem with the user experience? Now you'll have to make a source code change to correct this. I would only allow the technique you asked about if it controlled code that is specific to debugging -- never for code that is specific to release. Sorry I didn't get what you were doing -- on first read I thought you were doing something specific to the _un_-released versions.
Heath Hunnicutt
well, you could do that too - but what's the difference?
nickf
the difference would be this: if you use the method you mention to enact debug-only code, the release version would presumably fall back to some other method for the cache time. I assume that PHP provides some normal way to adjust the cache time other than in your source, I dunno. If that assumption is correct, then the difference is to have exceptional code override the setting due to the SVN variable vs. release code still obtaining the value from the PHP default setting.
Heath Hunnicutt
+1  A: 

This is a really bad idea, IMO. If you need configuration management, do it using configuration files and conditionals. Don't depend on your source code control system for configuration management.

tvanfosson
+1  A: 

Not a good idea. A much better way to achieve this would be to assign the version/build number as part of of a continuous integration or build process. This can be done in .Net by changing the AssemblyInfo.cs file before building.

Chris Missal
+1  A: 

I would consider this unacceptable, because you may at some point in the future migrate to a different source control system, whereupon this house of cards would come crashing down. It would come crashing down in a way that was (a) hard to detect, and (b) hard to fix.

Greg Hewgill