putty-source/doc/vids.but

\# Fallback versionid for use when the build system hasn't provided a
better one.

\versionid no version information available
Rework versioning system to not depend on Subversion. I've shifted away from using the SVN revision number as a monotonic version identifier (replacing it in the Windows version resource with a count of days since an arbitrary epoch), and I've removed all uses of SVN keyword expansion (replacing them with version information written out by Buildscr). While I'm at it, I've done a major rewrite of the affected code which centralises all the computation of the assorted version numbers and strings into Buildscr, so that they're all more or less alongside each other rather than scattered across multiple source files. I've also retired the MD5-based manifest file system. A long time ago, it seemed like a good idea to arrange that binaries of PuTTY would automatically cease to identify themselves as a particular upstream version number if any changes were made to the source code, so that if someone made a local tweak and distributed the result then I wouldn't get blamed for the results. Since then I've decided the whole idea is more trouble than it's worth, so now distribution tarballs will have version information baked in and people can just cope with that. [originally from svn r10262] 2014-09-24 10:33:13 +00:00			`\# Fallback versionid for use when the build system hasn't provided a`
			`better one.`
Now we use Subversion, it seems excessive to have an individual $Id$ line for every single .but file at the bottom of each page of the HTML PuTTY docs. However, we can't _always_ replace that with a single SVN revision, because there isn't always one available (SVN still allows mixed working copies in which some files are deliberately checked out against a different revision). Hence, here's a mechanism for doing better. It uses `svnversion .' to determine _whether_ a single revision number adequately describes the current directory, and replaces all the version IDs with that if so. If it can't do that, it uses the version IDs as before. Also, this allows an explicit version string to be passed on the make command line which will override _both_ these possibilities, so that release documentation can be clearly labelled with the release version number. [originally from svn r4804] 2004-11-17 18:16:59 +00:00
Rework versioning system to not depend on Subversion. I've shifted away from using the SVN revision number as a monotonic version identifier (replacing it in the Windows version resource with a count of days since an arbitrary epoch), and I've removed all uses of SVN keyword expansion (replacing them with version information written out by Buildscr). While I'm at it, I've done a major rewrite of the affected code which centralises all the computation of the assorted version numbers and strings into Buildscr, so that they're all more or less alongside each other rather than scattered across multiple source files. I've also retired the MD5-based manifest file system. A long time ago, it seemed like a good idea to arrange that binaries of PuTTY would automatically cease to identify themselves as a particular upstream version number if any changes were made to the source code, so that if someone made a local tweak and distributed the result then I wouldn't get blamed for the results. Since then I've decided the whole idea is more trouble than it's worth, so now distribution tarballs will have version information baked in and people can just cope with that. [originally from svn r10262] 2014-09-24 10:33:13 +00:00			`\versionid no version information available`