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 merge)
4.2.8 Merger (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).
(Continued)
