Tools-Automatically generate version numbers in SVN-based code

SVN is generally a team work to do a project needs to be, in order to be the version of Unity, I now use the version is Ankhsvn-2.1.7141.181.msi
SVN out [svn checkout]: Remove the working copy from the archive.
Outbound [Export]: A clean working copy is remitted from the archive and does not contain the SVN management data clip.
Import [Import]: Import the directory into the archive.
SVN COMMIT[SVN sent]: Send your changes to the archive.
SVN UPDATE[SVN UPDATE]: Updates the working copy to the latest version of the current archive.
Update to reversion[updated to version]: updates the working copy to a specific version of the current archive.
Get lock[Lock]: Lock Some files, you can only modify. Until you unlock the lock.
branches/tags[Branch/tag]: Quickly create a replica in the archive for use as a branch or tag.
switch[Toggle]: Switch working copy to other branches, tags.
merge[Merge]: Merges the branch tree back into the trunk.
Blame[condemns]: Lists the author of each line of the file.
Create patch[Create a patch]: Create a single profile that contains all of your modifications.


The following is a detailed description of the book read
1. Check out--get code from server side
Take out a project code stored in the server repository and put it in the local host, which is called "Check out". Use specific steps: Go to the directory where you want to install the project files, right-click, select the SVN Check out item, then fill in the original path and installation path of the project and click "OK".
2, update--Update Project code
A previously checkout project code, when the server has updated code, or local code corruption or loss, update can automatically determine which files are older, or missing, will automatically update. Of course, you can also remove the local code and check out again. Use the following steps: Right-click on the item you want to update and select the "SVN Update" key.
3. commit--upload Local code to the server
When you modify (add, delete, modify, and so on) The local code, the move will commit the new code to SVN. If the local code is modified and no commit is performed, the new version will not be available on the SVN server, which means that no one else will get it. Once the code has been modified, commit as soon as possible. Use specific steps: Right-click on the item you want to upload and select "SVN Commit".
4. export--export the project to a local
If you want to get a complete project, and do not need to make any changes to the version, you can export the project directly to the version control system, as a normal file for use. The steps are: Right-click, select the Tortoisesvn-->>export item, and then fill in the items to be exported.
5. Show log--all versions
If a project member wants to view all previous versions of a project that are downloaded locally in version control, right-click the item and select the Show log item under the TortoiseSVN menu. All versions of the project and each version of the modification information are displayed in the New dialog box that appears for reference by the project members.
6. Update to revision--revert to a version
When a project member wants to restore an item to a previous version, right-click on the item and select Update to Revision under the TortoiseSVN menu, then click "Show Log" in the Update dialog box that appears To view and determine the version number you want to revert to, or just fill in the edit area next to "Revision", and then click OK. As a result, the project reverts to the desired project version.
7. add--Add File
When a project member wants to add a new file to the project, copy the file to the project file and then, right-click on the file and select the Add Item under the TortoiseSVN menu, and the file can be added to the project.

Advanced Features
1. Update to Revision
Update defaults to the latest version, and update to revision can be updated to the specified version (which can be the older version).
2, adding and deleting the project files and directory operations
Add or delete the files or directories within the project, make sure to use SVN, or SVN del or svn rename, and then do a commit operation.

This section discusses the assembly version of the last one to use the SVN version number of the automatic generation method, here is a brief introduction to you, welcome to join me to learn the SVN version number of the relevant knowledge.
When using SVN for source code versioning, we want to be able to quickly find the source version for each release version, and now we can implement our requirements by adding SVN source version information to the assembly's version information.
Now we define the last segment of the version information for each assembly to represent the source version of SVN. The details are defined as follows: The
assembly version number is divided into 4 segments, such as 1.0.4.23.
The first paragraph is the main version number, and the project one but startup does not change. The second paragraph of the
is the minor version number, which is incremented when the project function is larger, with an increment of 1. The third paragraph of the
is the revision number, which is usually increased by 1 or 2 in the case of defects or minor feature changes. This version number is divided into odd and even two kinds. An odd number indicates a beta version, and even numbers indicate a stable version. The fourth segment of the
is the SVN source version number, which is automatically generated by the script.
Prerequisites for automatically generating SVN version numbers using scripts:

Install TORTOISESVN;
The source code is under SVN version management control.
Modify the project settings to automatically generate the SVN version number:
Modify the Properties\assemblyinfo.cs file to change the last segment of the assembly version information to $wcrev$. and add a line "//Last release: $WCDATE $"
For example:
[Assembly:assemblyversion ("1.1.0. $WCREV $")]
[Assembly:assemblyfileversion ("1.1.0. $WCREV $")]
Last release date: $WCDATE $
Rename the AssemblyInfo.cs file to Assemblyinfo.tpl and add it to source control.
Remove the AssemblyInfo.cs from the source code repository and exclude it from version management.
Add the Generateassemblyinfo.bat file in this article to the Properties directory and add it to source control.
Modify the project properties to add the following command on the pre-build event command line that generates the event.
"$ (ProjectDir) \properties\generateassemblyinfo.bat" "$ (ProjectDir)". \properties\assemblyinfo.tpl.\properties\ AssemblyInfo.cs
Attention:
Remember to commit your changes and update other people's changes before compiling to make sure that the version number is correct.
When you want to make changes to the assembly information in the future, please modify the Assemblyinfo.tpl file.
If the generated AssemblyInfo.cs file is garbled in Chinese, open assemblyinfo.tpl, and in the Advanced Save options file, change the file encoding to UTF-8. This section describes the SVN version number issue.

1. Generate a project named Autover
Note There is a file named AssemblyInfo.cs under the Properties folder of the project, and the version number of the Autover program is written in it.
2. Create a template file
In Windows Explorer, go to the Properties folder, copy the AssemblyInfo.cs file, name it AssemblyInfo.template.cs, and add it to the project.
3. Modify the properties of the AssemblyInfo.template.cs
The AssemblyInfo.template.cs file is a template file that is used to automatically generate the version number, it should not be compiled, so we want to change its build action to none, as shown in:
4. Modify the contents of the AssemblyInfo.template.cs
In this file, you can find the following two lines of code:
[Assembly:assemblyversion ("1.0.0.0")]
[Assembly:assemblyfileversion ("1.0.0.0")]
The "1.0.0.0" is the version number of the program, which uses the "major version number." The minor version number. The build number is in the form of the revision number. The first three changes to the number you need, the last one to change to "$WCREV $", after the change should be similar to the following appearance:
[Assembly:assemblyversion ("1.0.0. $WCREV $")]
[Assembly:assemblyfileversion ("1.0.0. $WCREV $")]
At the end of this file, you should also add the following two pieces of code that can detect locally modified (modified but not committed) code and a mixed version of the code.
#if $WCMIXED? true:false$
#if DEBUG
#warning Mixed Update Revisions founded
#else
#error Mixed Update Revisions founded
#endif
#endif

#if $WCMODS? true:false$
#if DEBUG
#warning Local Modification founded
#else
#error Local Modification founded
#endif
#endif
5. Modify Project Properties
On the Build event page of the project properties, enter the Pre-build event command line:
"%programfiles%/tortoisesvn/bin/subwcrev.exe" $ (solutiondir) $ (ProjectDir) Properties/assemblyinfo.template.cs $ ( ProjectDir) properties/assemblyinfo.cs-f
Note that we must ensure that the TORTOISESVN is installed on the default path. In many people to participate in the project this should be mandatory requirements, otherwise, everyone installed path is not the same, a machine can be used on the configuration, to the B machine may not be.
You may also need to turn off the automatically increment revision with each publish option in the Publish page (I'm not sure if this step is necessary). C # can increment its own version number, but the version number it generates does not correspond to the code in the code base, and I personally don't think it makes much sense. And it could also confuse our version self-amplification mechanism. So it should be turned off.
6. Add Project to Repository
Use VISUALSVN's Add solution to Subversion command to add the project to SVN, but do not commit.
7. Exclude AssemblyInfo.cs files from SVN
This file will be regenerated based on AssemblyInfo.template.cs each time it is compiled, so it is not necessary to join the repository. Once this is done, you can submit the entire project.
8. Compiling
Once the compilation is complete, look at the version information of the generated Autover.exe file, in this case 1.0.0.1. Whatever pity Dorado, commit, recompile, you'll find it automatically becomes 1.0.0.2, which is the revision number of the program is always the same as the revision number of the code that generated it. So, when the program goes wrong, we can easily get the version of the code that generated it with this number.
9. Other issues
In the 8th step, you may see a warning or an error message when you make the changes and then compile, saying the code has local modifications or mixed versions. This is the 4th step, in the AssemblyInfo.template.cs file last add two code, they detect whether the code has been committed and the version is consistent, once the problem will be found in the debug version of the warning message, in the release version of the error message generated. Using this approach, we can basically eliminate the possibility of inconsistent versions of published programs and versions of code. It's easy to get rid of these two errors or warnings, either by submitting or updating the code as a whole.

Tools-Automatically generate version numbers in SVN-based code