Polish some outdated pieces of documentation, eliminating almost all …

…SVN references

DEVINFO

@@ -27,11 +27,6 @@ src/obstacle	- collision detection
 src/ogl		- wrapper classes for OpenGL
 src/scene	- scene graph
 
-Developers should make only the most essential modifications in the
-BZFlag source tree to these third party packages.  This means that we
-allow them to install extraneous files such as documentation and
-headers into the BZFlag binary tree.
-
 game independent, platform dependent libraries
 ----------------------------------------------
 src/date	- build dates and versioning
@@ -104,8 +99,8 @@ interface header if there is one, or common.h otherwise, system
 headers, common implementation headers, and then local implementation
 headers.
 
-Adhering to this order will avoid nasty
-ordering dependencies and makes it easy to change things down the road.
+Adhering to this order will avoid nasty ordering dependencies and
+makes it easy to change things down the road.
 
 Ideally, there should be one class per file.  There are, of course,
 exceptions to this such as simple utility classes that are local to
@@ -149,11 +144,11 @@ If an extension can not be avoided then it must be able to be disabled
 or replaced using a #define in config.h.  BZFlag is a cross-platform
 application so it is important to remember that not all builds will
 use your specific compiler. This also includes not using features
-in C99 and C1x as the windows compiler only supports C++11 and 
+in C99 and C1x as the windows compiler only supports C++11 and
 there are some features in the later C versions that were not adopted
 by the C++ standard, namely the 'not' and 'or' keywords instead of ! and ||.
 Also MSVC seems to be a bit picky about what bits of older standards it
-supports. When the windows compiler supports this, we should stick with 
+supports. When the windows compiler supports this, we should stick with
 a consistent method and not mix AND with &&. Use the same type of operators
 that are in the existing code.
 
@@ -407,23 +402,25 @@ of the application should be incremented.
 The displayed application version includes additional information in
 the format:
 
-  Major.Minor.Revision-BuildOS-BuildType-BuildDate
-
-BuildOS is the operating system that the building system is running;
-on systems that use the automake build system this is automatically
-generated.
-
-BuildType is a string that represents the intended use of the build.
-For development releases, the build type is normally "SVN".  For
-testing releases, the build type can be "testing", "beta",
-"releasecandidate", etc.  For final release versions the build type
-should be "release".  The build type provides a human readable keyword
-for the version and intended or expected stability of the build.
+  Major.Minor.Revision-BuildDate-BuildType-BuildOS
 
 BuildDate represents the date of the build in the format YYYYMMDD.
 This string is generated during runtime by the compiler's preprocessor
 __DATE__ macro.
 
+BuildType is a string that represents the intended use of the build.
+For development releases, the build type is normally "DEVEL".  For
+testing releases, the build type can be "ALPHA", "BETA", "RC1" etc.
+For final release versions the build type should be "STABLE" or
+"MAINT".  The build type provides a human readable keyword for the
+version and intended or expected stability of the build.
+
+BuildOS is the operating system that the building system is running;
+on systems that use the automake build system this is automatically
+generated.
+
+If a build includes SDL or SLD2, the build string ends in "-SDL" or
+"-SDL2", respectively.
 
 Making a Release
 ================
@@ -440,7 +437,7 @@ cannot proceed.  A checklist of items to be completed follows:
   latest changes.
 
 - Version numbers are updated to the next expected release number.
-  This minimally includes updating README, ChangeLog, configure.ac, 
+  This minimally includes updating README, ChangeLog, configure.ac,
   buildDate.cxx, bzflag.rc, and the title.png image.  Version numbers in all
   other platform-specific README.* files should also be verified.
 

README

@@ -83,11 +83,11 @@ for common problems specific to those platforms as well.
 
 The Longer Version:
 
-To build sources checked out directly from SVN you need to create a
-configure script. You can skip this step if you grab an distribution
-of BZFlag that already has a ./configure script in it, such as from a
+To build sources directly from a git clone you need to create a
+configure script. You can skip this step if you grab a distribution of
+BZFlag that already has a ./configure script in it, such as from a
 source distribution tarball.  To generate the configure script, you
-run the provided autogen.sh script:
+need to run the provided autogen.sh script:
 
   % sh autogen.sh
 
@@ -215,7 +215,7 @@ man pages. This should get things back to a tarball state.
 `make maintainer-clean' removes everything distclean does and also
 packages, directories created during the build, and the platform
 configuration; this should get the source tree back to its state in
-SVN.
+the Git repository.
 
 To build BZFlag for an unsupported platform, see PORTING.
 

README.Linux

@@ -45,7 +45,7 @@ make
 
 The autogen.sh step can be skipped if the source code was received
 from the tarball package, but must be included if the source
-came from SVN.
+came directly from a git clone.
 
 This will build bzflag. If you wish to install the executables to
 the usr directory after the build then execute;

README.MINGW32

@@ -113,12 +113,10 @@ Q. When I run ./configure, sed dumps the contents of version.h, configure
    continues normally for a while, and then I get repeated sed errors like
    "sed: <file>: unterminated `s' command" and others.  Make fails with
    "*** No targets.  Stop." or similar.
-A. When checking out the bzflag sources from SVN, you must check them out with
-   UNIX line breaks.  For instructions for TortoiseSVN, see Part IV.
-   Alternatively, use mingw's or cygwin's built-in SVN to check out the files.
-   If you're using a source package, you need to use the tarball (.tar.bz2) not
-   the zip package.  You can extract it from within MSYS with "bunzip2 <file>"
-   and "tar -xvf <file>".
+A. When checking out the bzflag sources from a git clone, you must check them
+   out with UNIX line breaks. If you're using a source package, you need to use
+   the tarball (.tar.bz2) not the zip package.  You can extract it from within
+   MSYS with "bunzip2 <file>" and "tar -xvf <file>".
 
 Q. When I run make, it reports an error about not being able to find dsound.h.
 A. Follow the above directions to get the needed DirectX headers from the MS DX SDK,