If you need to copy, spread, please attach this statement, thank you. Original source: http://morningspace.51.net/ ,moyingzz@etang.com
4.4 Other Actions (Other USE)
4.4.1 Extend Keywords *
VSS can insert some specified information (eg, VSS internal version numbers) into the text file. Users will automatically find these keywords every time you add (Add) or check in the check in file, VSS will automatically find these keywords each time you add (Add) or check in, and place the relevant information. Keywords commonly used in VSS:
Keywords $ Archive: $ file in VSS name $ Author: $ The most recently changed file users $ Date: $ recently checked in History: $ file history $ revision: $ VSS internal version number $ NOKEYWORDS: $ Make VSS to all keywords, for example: Add to the following line in a file: $ revision: $ If the file is currently the version number inside the VSS is 22, the VSS will be Change to: $ REVISION: 23 $
4.4.2 Use Shadow Directory (Work with Shadow Folders) *
The shadow directory is located in the server side, which contains all the files in the project. These files are both Master Copy located in the VSS database, also not in the local working directory Local Copy, but all the contents of the last check in. The shadow directory should be set by administrators. Whether to use Shadow directory is optional, usually use this function in both cases:
To enable some users to view files (but cannot be changed), these users may not have access to VSS. Don't let your local work catalog retain compiletable software copies. In order for each user to get a new version of the software, all users may want to compile in a directory, rather than compilation in their respective working directory. In this case, the shadow directory function is usually used in conjunction with the Remove Local Copy after the addition (ADD), check in. The Shadow directory will not track the changes of sub-projects, for example: you have a SHADOW project $ / A, including two sub-projects: $ / A / 1 and $ / 2, and you will be $ / a / 2 Name $ / A / b, this change will not be reflected in the shadow directory. You can modify it manually, or use the Reconcile All to keep it synchronized.
4.4.3 Performance (Optimize Performance) *
There are two ways to improve the performance of VSS: as much as possible to copy content through the network to local; modify the initialization file to fine-tune the performance of VSS. Specific optimization measures:
Set the following variables in the ss.ini or srcsafe.ini file: Diff_Ignore (PC) = CESW- ignores the end-of-line tag when the VSS is compared, thus speeding up the running efficiency cp_onselection = no in using VSS Explorer, lack In state, users use the mouse click or use the direction of the keyboard to move on the project list, and will be selected. After setting to NO, only double-click the mouse or press Enter key. Setting the Temporary Directory default, VSS exists to the server side, but the administrator can set the temporary path locally by modifying the TEMP_PATH variable in the ss.ini. Let the administrator in the srcsafe.ini file to set the lock_mode variable to Native This is the default setting of this variable in srcsafe.ini, which sets the variable to native will allow almost all VSS operations to accelerate. This variable can only be set by administrators. Administrators can improve performance by DISABLE: Shadow Folders Journal Files Project Security System (see Secure Access) Keyword Expansion (see Extension Keyword)
4.4.4 Find file (Search for Files)
VSS Explore's List view defaults only all files in the current project. By using the search command, only files that meet the specified requirements can be displayed. For example: only display .h file, only realistic files being checked out. The Search command is allowed to be recursive.
4.4.5 Set Passwords
If the VSS administrator specifies that the domain account is VSS login account, the user will not prompt the input password when the user logs in to VSS.
4.4.6 Write Batch File (Writing Batch Files) *
Some interactions used in command line needs to be changed when writing batch files.
Shield Input If your batch file contains a series of VSS commands (they may need to run all night), you must not want the program to stop prompting the user to enter information during execution. There are 3 command line options to solve such problems. By default, the VSS prompts you to enter a comment when performing operations such as adding (add), check in, and use the -c option to avoid this category:
Command Description -C- Do not add a comment "-chello" Using the Hello string as a comment - C@comment.txt Use the content.txt file as a comment, VSS usually requires the user to answer Yes or No, you can use -i Option avoids such problems:
Command Description -i-y Auto Answer all this kind of question Auto-answer NO-i automatically answers NO-i using the default answer vss for all such levels VSS, you can prompt the login, you can use the -y option to provide sufficient information. When redirects the output default, VSS directs all output to the screen, where you can use the -o option pagination in the command line, and you can also use the -O shield output or redirection output in the batch file.
Command Description -O-Mask Output -oresults.txt Redirects All Output to Text Files RESULTS.TXT, if the file already exists, the output will be appended to the end of the file. When using the command line return value runs VSS in the command line state, VSS sets some return values to indicate the running status. You can take the corresponding measures based on the return value of VSS in the batch file.
Return Value Description 100 indicates an error, for example: VSS can't find a database file, or you try to check out a file that has already been checked out. 1 shows that one is not a very serious mistake, will happen in the following three cases: When you use SS DIR, no entries are found. When you use SS Status, at least one is checked out. When you use SS DIFF, at least one file is inconsistent. All of these situations indicate that even if this operation is successful, the next VSS command you perform may fail. 0VSS successfully executed. 4.4.7 Custom SS.INI and Srcsafe.ini files (Customize the ss.ini and srcsafe.ini files)
VSS has two types of initialization files that contain some environment variables for VSS: SS.INI, each user has such a file; Srcsafe.ini, only one, defined some global variables of VSS, only administrator Have the right to modify it.
Appendix also maintains multiple versions of a project (MAINTAIN MULTIPLE VERSIS OF A Project)
You can use the Label mode using Share / Pin / Branch. If your environment only requires a small amount of changes, such as: lightweight Patch, use Label is appropriate; if you are planning a lot of development content, use Share / Pin / BRANCH appropriate. For example, when the software is in a beta version, you can freeze (freeze) and modify the BETA version of the BUG. When you maintain a product from version 1.1 and 2.0, reasonable approach is to create a new project, Share and PiN all files, when needed. When 1.1 is released, you can re-Merge to version 2.0 of the 1.1 version of the project. The following scenarios provide guidance for you to use the Label feature: Scene 1: Ideally 1. Develop and test the project to reach the beta 1 version. 2, when you think the time is suitable, Label will be "beta 1". 3, start the work of beta 2. Scenario 2: Some versions of file a are incorporated in the Beta 1 version, develop and test the project that is about to reach the Beta 1 version. 2, when you think the time is suitable, Label will be "beta 1". 3, start the work of beta 2. 4. If the version of the file A is found to be included in the beta 1 version, select the correct version of the file and Label is "Beta 1". 5. Get the project of (GET) Beta 1. Scenario 3: The file A after bug-fix is included in the Beta 1, and the remaining files have not been changed 1. Develop and test the project to the Beta 1 version. 2, when you think the time is suitable, Label will be "beta 1". 3, start the work of beta 2. 4, you find that there is a bug that contains the version of the file a in the beta 1 version, and the rest of the project must not be changed. 5. Check out the file, correct, and then check it. 6, re-lable the project "Beta 1" (you will be asked if you confirm the original tag). Scenario 4: Need to include bug-fixed file a in the Beta 1, and the rest of the files are also changed 1. Develop and test the project that is about to reach the Beta 1 version. 2, when you think the time is suitable, Label will be "beta 1". 3, start the work of beta 2. 4, you find that the version containing file a in the beta 1 version is bug, and the remaining files in the project have been changed and have been signed. 5. Check out the file, correct, then check into (the VSS internal version number of the file will be added automatically). 6. The file Label is "Beta 1" (and the work of the project), which will make the existing version of the file to be "beta 1". Scenario 5: An original version of file A requires bug-fix, and join the Beta 1 version 1. Develop and test the project that is about to reach the Beta 1 version. 2, when you think the time is suitable, Label will be "beta 1". 3, start the work of beta 2. 4. You find that there is a bug that contains the version of the file a in the beta 1 version. It must be corrected. For example: The current internal version number of the file is 6 and contains some changes to the Beta 2 version, and you don't want to incorporate these changes into the beta 1.
