deployment: Update README.txt to accurately reflect the role of the deployment directory

deployment/README.txt

@@ -2,11 +2,35 @@ This deployment folder contains files that describe how a release of TTR should
 
 uberdogs.yml contains the 'uberdogs' section of an astrond.yml. Please keep it updated, or else you'll break prod!
 
-deploy.json describes a specific release of TTR. It contains the version of astron to use as well as the version of Panda3D to use.
-deploy.json also contains a version prefix. For releases, a commit should be made that updates deploy.json to state the new version prefix.
+deploy.json describes a the environment for a release of TTR. It contains the version of astron to use as well as the version of Panda3D to use.
+deploy.json also contains a version prefix. This is used to generate dev version strings on the development server (which are probably something like ttr-beta-dev-gabcdef0).
+When we deploy a release to prod, we push a git tag named after the version to the repository (i.e. ttr-beta-v1.3.7). It is required that the tag's name contain the version prefix specified in deploy.json.
 The key 'server-resources' maps to a list of file extensions of files in the resources directory that are necessary to be used server-side. We do not package and deploy art assets onto servers.
-For example:
-deploy.json resides at prefix ttr-v1.0.1-
-Git commit 6ebecf60d contains all the code that we want to push in v1.0.2
-Whomever is making the release should create a single commit changing deploy.json's version prefix to ttr-v1.0.2-. Don't put anything else in that commit. Say it has commit hash 102bea8c9.
-The final rendered version number, after deploy scripts are run, would be ttr-v1.0.2-102bea8.
+
+Last, server.prc is the configuration file we use for specifying config vars related to gameplay (a variable like want-sbhq should be put in server.prc, while a variable like air-stateserver does not belong here). server.prc is the last portion added to generated configuration files.
+We also have a tag system to allow certain blocks of configuration to be used only in a certain environment. This allows us to generate releases that behaive differently depending on the environment that they are deployed in. For example:
+
+-----
+want-toontowncentral #t
+#<prod>
+want-bbhq #f
+#</prod>
+
+#<dev>
+want-bbhq #t
+#</dev>
+-----
+
+In prod, the parsed config file would look like this:
+
+-----
+want-toontowncentral #t
+#<prod>
+want-bbhq #f
+#</prod>
+
+#<dev>
+##UNUSED SECTION
+##want-bbhq #t
+#</dev>
+-----