If you need to copy, spread, please attach this statement, thank you. Original source: http://morningspace.51.net/ ,moyingzz@etang.com
As a management tool for version control, although Microsoft's Visual SourceSafe has many things that are not satisfactory, this is also complained. But I think that more use is inconvenient, because it is caused by unfamiliarity of the tool. This tutorial is that the author is adapted according to the VSS online help documentation when examining version control a few months ago. It is said that it is a tutorial, but it is better to say a concise manual because its content covers all the functions of VSS and extracts self-conscious and valuable things, and translates it into Chinese. Among them, there are good suggestions and use techniques, such as: Regular backup of the complete VSS data directory, regularly clear the contents of the temporary directory, try to use a data inventory to put all the files, use virtual rollback (Virtual rollback) instead of ordinary rollback, exclusive sign Use, Cloak operation, etc., not enough.
For branch / share / pin / label, the combination of these functions, the relevant parts of the body and appendix provide a quite good example, demonstrate how to use the flexible use of the features to deal with different development scenarios. When I saw this part of the content, I had a sense of great achievements for a while, and I can't help but think that the original VSS can also be used. I believe that these examples will also have a small revelation and "shock".
In addition, the "VSS command-permission level corresponding table" of the appendix section is the result after the author's finishing. It has it. You can use what kind of feature to users with different permissions, and it will become a glimpse.
I hope this tutorial can help developers and managers who are not very familiar with VSS, and I hope I can take this opportunity to clarify some "prejudice" for VSS :)
Click here to view the Visual SourceSafe Concise Training Tutorial
Directory 1 Description 2 Overview 3 Administrator section
3.1 Maintenance User List
3.1.1 Adding User 3.1.2 Change Password 3.1.3 Creating User List 3.1.4 Deleting User 3.1.5 Editing User Properties 3.2 Managing Database
3.2.1 Analysis Data Contents 3.2.2 Database Package 3.2.3 Clear Temporary Contents 3.2.4 Lock Database 3.2.5 Database Recovery 3.2.6 Using Multiple Databases 3.3 Related Permissions
3.3.1 Transmission 3.3.2 Safety Access Right 4 Ordinary User Part
4.1 General use of engineering, document
4.1.1 Opening / Off Database 4.1.2 Creating a New Project 4.1.3 Add Files, Directory, Engineering 4.1.4 Delete and Recovery Files, Engineering 4.1.5 4.1.6 Rename File, Engineering 4.1.7 Settings Work Catalog 4.2 Check In, Check out, Get, View, and related
4.2.1 Check In Sign Operation 4.2.2 Undo Signing 4.2.3 Get the most recent version 4.2.4 Get Earlier Version 4.2.5 Get and View Files, Engineering 4.2.6 Roll back to previous versions 4.2.7 multi-person sign A file 4.2.8 merge 4.2.9 exclusive checkout 4.2.10 on the project's CLOAK operation 4.3 Branch, Share, Label and PIN operations
4.3.1 Branch / Share Operations for Files and Engineering 4.3.2 gives the file, project designated tag 4.3.3 PIN operation 4.4 Other operations
4.4.1 Extended Keyword 4.4.2 Using Shadow Contents 4.4.3 Performance Optimization 4.4.4 Find File 4.4.5 Setting Password 4.4.6 Write Batch Document 4.4.7 Custom SS.INI and Srcsafe.ini file Appendix
A1 also maintains a corresponding permission level of multiple versions of the A2 VSS of a project
Schedule VSS Correspondence Level
In the table below, the star indicates that the user with this type of authority can use this command.
Function rcadadd ** branch ** check in *** check out *** cloak **** create [1] ** delete ** destroy * Difference **** get Latest version **** history **** Label ** links **** merge [2] *** merge **** move [3] ** move * Pin *** purge * recover ** rename ** rollback * share [4] *** Share ** undo check out *** SET WORKING FOLDER *** [1] Here, the user must have a Class A permissions to the Parent Project. [2] Here, the user must have Class C permissions for the purpose of PROJECT, while there is R-class permission to the original Project. [3] Here, the user must have a Class A permissions to the destination Parent Project, and there is a D-class permission to the original Parent Project. [4] Here, it means that the user must have Class C permissions on the original Project, and there is a Class A permission to the destination Project. 1 description
First, this tutorial provides several use instructions for Visual SourceSafe 6.0 for different use objects, including Visual SourceSafe administrators and ordinary users, and want to know how to use Visual SourceSafe to control managers. Administrators or ordinary users can check this tutorial if you have anything you don't know if you don't know how to do it, or you don't know how to do it, or you don't know much about some operations. Second, the "administrator part" of this tutorial is the administrator must read. If the administrator also serves as a normal user role in addition to its own responsibilities, please refer to the "Ordinary User Part" in the tutorial. As a general ordinary user, just read the "ordinary user part". Third, the operation listed in the tutorial, plus star, is an advanced usage, and the rest is Basic USAGE. The so-called basic usage means that some operations are often used frequently, or is more simple to use. The so-called advanced usage means that there is not much frequency, or more important, or more useful. 4. The content of this tutorial is selected and adapted from the Visual SourceSafe 6.0 English version of the online help, and many important information is extracted, and the content that is easy to ignore and a number of precautions. Some basic contents (mainly referring to the use of certain basic operations) Simply list entries, please see the details of these entries, please check the connection between the online help, you can search in online help after listed by these entries. To related content. 5. This tutorial does not involve the explanation of the Visual SourceSafe graphical user interface operation, check the relevant section of the online help for the specific operation steps for the specified function. Related content can be searched in online help by listed in this function. Sixth, in other Visual Studio products (for example: Visual C ) can integrate Visual SourceSafe, this tutorial does not involve how to use the Visual SourceSafe function in other integrated development environments, this part of this part is primarily for ordinary users. The understanding of these contents will become easy after reading the tutorial. In addition, some operations are more convenient in the Visual SourceSafe environment.
2 outline
Visual SourceSafe (hereinafter referred to as VSS) is a version control management tool. It helps you effectively manage projects by depositing various types of files (including: text files, image files, binary files, sound files, video files, etc.) into their internal databases (Project, the concept of engineering in VSS) Please see below). It allows you to share the same set of files between multiple projects; you can add a file to the database so that other related personnel are used; any changes to files will be recorded so that you can restore it to the file at any time. An old version. VSS engineering organizations make team collaborative development easier and intuitive. A project is an arbitrary type file stored in the VSS database, a project similar to a directory in the operating system, but VSS provides more functional support for version control, history, file merge. 3 administrator part
3.1 Maintenance User List (Maintain The User List)
3.1.1 Adding a user (Add A User)
If you are here, please refer to the online help.
3.1.2 Change Passwords (Change Passwords)
If you are here, please refer to the online help.
3.1.3 Creating a list of users (CREATE A User List)
If you are here, please refer to the online help.
3.1.4 Delete Users (Delete a User)
If you are here, please refer to the online help.
3.1.5 Edit User Attributes (Edit User Attributes)
If you are here, please refer to the online help.
3.2 Management Database (Manage the Database)
3.2.1 Analysis Data Directory * It is recommended that you regularly back up the full VSS data directory (see Database Package). The VSS data directory contains database information with all the projects and files. Due to certain faults of the network or operating system, the files in the VSS may exist errors and inconsistencies, and the Analyze VSS DB tool is used to find and fix these issues. Before running the tool, you need to lock all users and ask them to exit the VSS, and the user can keep the file checklist when a database is locked (see Lock Database). It is recommended to run an Analyze VSS DB tool twice, the first repair error, whether the second verification still does not have a fixed error. The specific location of the data directory is specified by the Data_Path initialization variable in the srcsafe.ini file (see custom SS.INI and SRCSAFE.INI files).
3.2.2 Database Packaging (Archive Databases) *
You may need to back up the VSS database regularly, or some part of the database. The VSS Administrator tool provides this feature. it can:
Save the disk space of the VSS database server. Accelerate the speed of display history. It is convenient to pass files and projects between multiple VSS databases, and keep history is complete and free. Back up all or part of the VSS database content and compress into files. 3.2.3 Clear Temperature Folder (Clean Temporary Folder)
VSS is usually placed in a temporary directory at runtime and deleted it before exiting. For some reason, such as abnormal restarts, the temporary content may remain in the directory. As an administrator, you have a responsibility to regularly clear the content of the temporary directory. Every few weeks, when no user runs VSS or VSS Administrator, clear the contents of the temporary directory. The specific location of the temporary directory is specified by the TEMP_PATH initialization variable in the srcsafe.ini file (see custom SS.INI and SRCSAFE.INI files).
3.2.4 Lock A Database The database lock function will not automatically lock the user currently logged in, and you should ask the user to quit the VSS before the database is locked. Before re-allowing users to use VSS, you need to unlock the database. 3.2.5 Database Recovery (RESTORE DATABASES)
If you are here, please refer to the online help. 3.2.6 Using multiple databases (Work with multiple data) *
In default, VSS places all files in a database. If possible, try to use a data inventory to put all files, which is better than multiple data inventory, because: You cannot share (Share) files between multiple databases (see BRANCH / Share operation on files and engineering). It is more difficult to set the contents in multiple databases, and you need to use the VSS Administrator's Archive function (see Database Package). For security considerations, VSS user information, including password, is stored with data. If you want to split information into multiple separate databases, VSS is set to a database in a database. If possible, try to use a data inventory to put all files, which is better than multiple data inventory, because: You cannot share (Share) files between multiple databases (see BRANCH / Share operation on files and engineering). It is more difficult to set the contents in multiple databases, and you need to use the VSS Administrator's Archive function (see Database Package). For security considerations, VSS user information, including password, is stored with data. If it is sure to split information into a plurality of separate databases, this information store will bring great convenience, but you must add users separately for each database. 3.3 Topics related to permissions (About Rights)
3.3.1 Transfer of Permissions (Rights Propagation)
When you add a new user, when you set the user's permissions for a project, you will build an ASSIGNMENT in the VSS database. The Assignment will pass down the project tree until you encounter another Assignment.
For example: For the project "$ /", you specify add permissions for User A (see Secure Access Permissions), and for project "$ / Sample", you did not explicitly specify permissions for users, the user will work "$ / Sample "automatically has Add permissions. When you specify the READ permissions at the project "$ / Sample / BusinessObject", you will prevent the downward transfer process of early ASSIGNMENT, so user A is the project (refer to "$ / sample / businessobject") and its sub-engineering Only have read permissions.
When you add a user for the first time, the permissions given by the project "$ /" are determined by the Default Permissions, and the default permissions are defined by setting the contents of the Project Security property page in the VSS Administrator. You can change all users' default permissions by modifying the contents of this page.
3.3.2 Safety Access Rights (Security Access Rights)
3.3.2.1 Default Security Settings
After installing VSS, the default security settings will be enabled. You can use customized ways to enable some users with specific permissions for certain projects and some VSS commands. The default security setting is simple. When adding new users, you only have two levels of access to access:
Read-Only Rights: The user can view anything in the VSS but cannot be changed. Read / WRITE RIGHTS: The user can view and modify anything in VSS.
If such access rights level is sufficient to cope with everyday use, there is no need to enhance the level of security control.
All VSS security management is done in VSS Administrator. Any user who can run the program can change any of the characteristics of the VSS, so it is best to use the program only.
3.3.2.2 Higher level security control
In VSS, the security control of the project is implemented by developing user access rights. Each project can only be accessed by users with corresponding permissions, each command can only be used by users with corresponding permissions. Permissions can be customized through VSS Administrator to achieve higher level security control.
The following is a list of VSS permissions, each of which has all permissions before this permission. For example: a user with Check Out permissions, will also have read permissions. (See Appendix A2: Correspondence Level of Commands in VSS)
Permission Description Read (R) Similar to read-only permissions in the default security setting Check Out (c) You can modify add (a) using the check out / check in / undo check out, etc., add / delete / label / Rename and other commands modify DESTROY (D) You can use DESTROY / PURGE / ROLLBACK to implement permanent deletion operations
4 ordinary user part
4.1 General use of the project and document (Normal Use About Projects and Files)
4.1.1 Opening / Close Database (Open / Close A Database)
If you are here, please refer to the online help.
4.1.2 Creating a new project (CREATE New Projects)
If you are here, please refer to the online help.
4.1.3 Add files, directory, engineering (Add files, Folders, and Projects)
If you are here, please refer to the online help.
4.1.4 Deleting and recovering files, Engineering (Delete and Recover Files and Projects)
VSS provides three ways to delete files:
DELETE: VSS only removes the specified file from the current project, and there is still a record of the file in the VSS database. In addition, other projects share this file still reserve this file (see BRANCH / SHARE operations for files and engineering). DESTROY: VSS will completely delete the specified file from the VSS database, which will not be recovered. PURGE: Permanently deletes files that have been dropped by Delete, will not be able to recover.
For shared files, Delete and Destroy only delete files from the currently selected project, and other projects share the project, and this file is left in the VSS database.
4.1.5 Moving Files and Projects
The only way to move a file is to share the file shared at the last level of the file in the new location of the file (see the Branch / Share operation of the file and the project), then subsequent projects under Original Project This file delete or Destroy (see delete and recover files, project). After moving, the history of the file will be retained. By using the Move command, you can reset a sub-engineering from a superior project to another. This operation does not change the content and history of the sub-project, but it will affect the history of the superior engineering (including the original superior engineering and new superiors where the sub-project is located). When moving a project, you will not be able to rebuild an old version of the original superior project.
4.1.6 Rename File, Rename Files or Projects
If a file is shared by multiple projects, the rename of the file will affect all works, and in the BRANCH state, it does not affect (see BRANCH / Share operation on files and engineering).
4.1.7 Setting Working Directory (SET WORKING FOLDERS)
If you are here, please refer to the online help.
4.2 Check In, Check out, Acquire, View, and related operations (Check In / Out, Get, View and Other Related Use)
4.2.1 Check In-Check Out Files
If you are here, please refer to the online help.
4.2.2 Undo Check Out
When this is executed, if the user selects the replacement local file, the user will lose the last check out after the file is changed locally.
4.2.3 Get the most recent version (Get Latest version)
If you are here, please refer to the online help.
4.2.4 Get Early Versions (Get Earlier Version)
If you are here, please refer to the online help.
4.2.5 Get and View Files, Engineering (Get and View Files and Projects)
GET operations copy files or projects to the local working directory and set to the Read-Only property. You can view the file content with the View operation, at which point the user does not need to set a work directory. Try not to delete the vssver.scc file. Local working directory and each subdirectory contains such files, VSS uses the information in which the information is determined which files have been changed. After deletion, the new GET operation will slow down.
4.2.6 Roll back to previous versions (Rollback to Previous Versions)
This operation will cause the content of the file to restore the status of the previous version, which will make all the changes made after this release. If the file you roll is shared by multiple projects, the operation only affects the project you specify, and it will automatically implement the BRANCH operation (see Branch / Share operation on files and engineering). It is recommended that you use virtual rollback (Virtual Rollback), which will not make subsequent changes permanently lost. The specific operation is as follows:
Select the file you want to roll back and check out to use the get command to get an original version to the local check into the file.
4.2.7 Many people check out a file (Check Out Multiple Files) *
Under the default, a file only allows one person to check out, and the administrator can allow multiple people to check out at the same time by modifying the configuration. At this point, VSS will track all users who check out the file. Whenever the user checks in, VSS will compare the latest version of the currently stored in the database. If the user changes the same file, the VSS will make a simple merge (Merge), otherwise prompt the user, and not allowed Check-in. Users can compare the Visual Merge tools provided by VSS, which are stored in the VSS database and the local files, and the local file is manually modified until the final check-in operation is performed when it is considered to be signed. (See the merge) 4.2.8 mergers (merge) *
In VSS, the merger may occur in three cases: using Multiple Checkout's working mode; combine the file originally already branch; get (GET) file.
Multiple Checkout: If multiple users check out a file, the first user is as long as it is easy to check in. Subsequent users can also check in, but their changes will need to be merged with all other users, and VSS will get complete change content (see multiple people at the same time check out a file). BRANCH: When merged to one of the branches by the BRANCH, the VSS will consolidate the changes on another branch to the branch (see the BRANCH / SHARE operation of the file and engineering). MERGE ON GET: In the Multiple Checkout mode of work, the merge operation may be caused when using the Get Latest version, and the content saved in the VSS database will be merged to the local file. However, if a file is exclusively check out, a merge operation is not triggered (see honest sign).
After completing a merge, VSS follows the following rules:
If there is still a conflict, the VSS maintains the check-out state of the file, in order to make the file to be able to sign into it, you must exclude these conflicts. If you use the merge branches command, merge a file into a project, and the corresponding file in this project has been checked out, which will continue to check out status (see Branch / Share action on files and engineering). At any time, VSS will prompt you, or automatically check in after the merger, or keep the file checkout to check the one before updating the contents of the VSS database.
By default, when a conflict occurs, VSS will enable its Visual Merge tool.
4.2.9 Exclusive Check Out * *
Allows multi-person to check out a file is for the entire VSS database, but users can still modify this rule for certain files according to the actual situation. Other users will not be able to check out the file until the user uses the check-in operation.
4.2.10 CLOAK PROJECTS *
If a CLOAK operation is implemented to a project, the project and its sub-project will not be affected when the previous project's last-level project is operated. When the work is performed in this engineering, the results of peace often result. This property will be passed to the subcommert below. For example: a project has a path to $ / Application, with three subcompices: $ / Application / Code, $ / Application / Test, $ / Application / DOCS, and DOCS projects may have no use of you. When you do GET every time you do your Get, you need to delete an extra DOCS directory from your local. The DOCs can be performed on the CLOAK operation. In this way, each GET operation will only put the contents under Code and Test to the local. If you need to get content under the DOCS project, you can do GET operations separately from DOCs. 4.3 Branch, Share, Label and PIN Operation (Branch, Share, Label and Pin)
4.3.1 BRANCH / Share Action on File and Engineering (Branch and Share Files and Projects) *
In VSS, through the Share operation, a file can be shared by multiple projects, changes to the file in any project, will be reflected in other related projects. BRANCH operations eliminates this sharing, and each time a shared file is disolded into two branches, tracking the file separately in different projects. You can understand which project shares of this file by viewing the file properties, you can learn about the branch of the file by viewing the Paths property page.
For example: The current official version of the product is 2.0 (the engineering path is $ / Application), and will be upgraded to 3.0 after joining the new feature. However, in the process of starting upgrades, a transition version 2.1 is a bug, which needs to be modified. You can do the following: Select the version of the Label ID of 2.0 (see to file, project designation tag), use the Share function to create a transition version (the engineering path is $ / application2.1), at this time in the two projects The file is shared, and all files in the $ / application2.1 are in the PIN state (see PIN operation), that is: During the 3.0 upgrade process, changes to related files in $ / Application will not affect $ / The content under Application2.1, but the file is still shared. BRANCH operation is taken only for files that need to modify bugs. The benefits of this is that the intermediate version of bug modification work and 3.0 upgrade work can be carried out simultaneously, and minimize the desired storage space.
4.3.2 Give a document, project designated label (label files and projects) *
VSS uses three ways to track history: internal version number, date, user-defined label. The label can be a string that does not exceed 31 characters, such as "1.0", "2.01b", "Final Beta", "AppRoved for QA". To apply the Label function, users can get software content for a particular period. All current works and sub-projects will inherit the label. Note the following:
When using the Label function, it indicates that you have created a new version in the history of the selected project, but the content of the file and the project itself did not change. Use the label operation again to use the Label operation to overwrite the original tag content. See Appendix A1: Multiple versions of a project while maintaining
4.3.3 PIN Operation (PIN) *
This feature is useful for shared files, although its use is not limited to shared files, including any other files. When you implement PIN for a file, you will not be able to make any modifications. If a file is also implemented after the PIN, the version of the PIN is also shared at the same time, and all the projects shared the file cannot be changed. If a file is first implemented by Share, then in a project is PIN, the file can be changed in addition to the remaining projects outside the project (see the BRANCH / SHARE operation of files and engineering).
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.
