Common terminology for version control software (CVS,SVN)

Sandbox: Sand Box
The difference between CCVS and most other version control systems is that it allows developers to edit the same file at the same time, first you should start from the warehouse

Take out a copy of the source code to your local computer, this local copy is called the sandbox

Make new module: Create a fresh warehouse or module
Create a new warehouse or module on the server.

Checkout: Remove
Create a local sandbox from the CVS repository.

Add: Add
Add local files or folders to the CVS repository.

Remove: Deleting
Deletes the client's file,
If you commit again, the file on the server is deleted, but it is not physically removed and can be recovered.

Commit: Commit
Submit your own modifications to the server
A good habit is to update the file before you are ready to submit it to the server, because it is possible that other developers will change the same

, you may also have modified the file, which is likely to be a conflict, and we always deal with the conflict before submitting it.

Update: Updating
Take the latest version from the server and be careful not to lose your changes
If you have modified the local version, the operation is unsuccessful, you can then select "Get Clean copy" to force the latest version of the server, the

Files will be backed up

Create tag: Creating labels
Develop to a certain stage, marking operations on multiple files.
Tags are always made when the project is issued or when major modifications are made. When the software is developed to a certain stage, the test is completed, there is a relatively stable and reliable

Version, if there is a new demand, need further development, if the program upload directly, you can not quickly get already stabilized

Fixed version. This requires the use of tags to achieve, as long as the stable version of the unified label, then download the direct selection of the download belt

With all the files on the label, you can quickly get the stable version you want

Create a branch: Creating a Branch
Isolate modifications to a separate development line

For example:
We designed a library management system, the 1.0 version to the customer A;
Then we continue to develop, with the new version 1.1, 1.2, 1.3 ... at this time a university told us that the 1.0 version of the bug, we soon

The error is found in version 1.0 of the source code. At this point, the simplest solution is to give a university a bug patch. You would ask, why

Do not give the customer the latest version.
The reason is simple: first, we have not checked the latest stable version of the bug, and second, the customer's system has been running for some time,

More new issues may occur when you upgrade to the latest version. So, we should build a branch on the 1.0 version, on this branch

Develop, modify bugs, create Bugpatch, and customers will soon be able to solve the problem. Then we closed the door and looked at the latest version without

This bug, and if so, merge the branches onto the main version to resolve the latest version of the issue.

Version: Edition number
w.x.y.z means:
W: Major version number, x: Minor version number
Y: Branch number, Z: Branch modification number

Files are displayed in different states with different icons: