SVN PK CVS

Version control tools SVN and CVS

Cvs I believe everyone has heard of it. However, this widely used version control tool still has many problems, including Chinese support and binary file processing.

Now, the author of CVS has developed SVN for us. The development teams of gnome and KDE have switched over to SVN. Why don't you try it?

Basic usage

Create a code library svnadmin create/path/to/repos to import data SVN import/path/to/project file :: /// path/to/repos-M "Initial import" export data SVN checkout file :: /// path/to/repos submit and update SVN commit filename add file SVN add delete file SVN delele copy file SVN copy mobile file SVN move query status SVN status check different SVN diff synchronization working directory SVN update merge code SVN merge; SVN resolve

Svn-related resources

Here is the svn project website.

 

<Version control with subversion>.

Here is the svn document of Traditional Chinese (only some of them have been translated ).

CVs that cannot be mentioned

Although I have already moved to the svn camp, CVS is still one of the most widely used version control software. Some resources about CVs are collected here.

Install and configure CVSD

Introduction to CVS

(Note: This is the information that oscargreat has prepared. I believe it will not matter if I use it :)

What is CVs?

CVS (Concurrent Version System) is a version control system in C/S mode. It is used to record file versions during software development and coordinates developers to ensure file synchronization, this ensures that the project is correctly developed in parallel and supports version rollback, bug tracking, and patch generation. Cvs can effectively manage and organize the source code and development documents of software development in a unified manner.

 

Working Mode of CVS:

The basic working mode of CVS is as follows:

CVS server (code document library)/|/(same step for version)/|/developer 1 developer 2 Developer 3

CVS maintains the code document library on the server. Different developers establish the corresponding code tree on the local machine and use CVS to keep the local code documents consistent with the Code document library. When multiple developers modify files simultaneously, causing code conflicts between the local and library files, CVS reports and helps solve the problem of merging conflicting codes. The procedure for normal developers (non-Administrators) to use CVS is as follows:

Check out (obtain) ------------------ Merge (merge) | ^ V conflict (conflict) | modify (modify)-> Update (update) ---------------- ^ | no conflict (no conflict) | V Update (update) <-commit (submit) | V Export (Export)

The check out command only needs to be used once when the local code tree is created. After that, the update command is used to update the local code. The update command compares the differences between the server and the local code library, and automatically updates outdated files in the local code tree. After modifying the code, you also need to use the update command before submitting the code to obtain the code modified by others in parallel. If a conflict occurs (that is, the same file is modified at the same time), CVS retains and marks both of them in the local code and requires the developer to handle the conflict. If the conflict does not exist or has been resolved, use the commit command to update the server code to the local code. CVS requires annotations for changes and automatically processes version numbers for updated files. When the software needs to be officially released, use the Export command to export the source code tree that does not contain CVS settings.

The CVS Administrator also uses commands such as init, import, and Admin to configure and set the server and code base.

Use of CVS on a Linux Client

Multiple ides/editors in Linux, such as Emacs and eclipse, provide support for CVs, but command line-based CVS operations are the most basic and flexible. The following describes how to use the CVS command line.

Environment Variable

Cvsroot specifies the location of the code base. If the CVS code base is on a local machine, you can directly specify the path of the code base, for example, export cvsroot =/path/to/cvsroot. If the CVS code base is on the server, you also need to specify the server location, communication mode and user information, format: cvsroot =: Method: username@cvs.server.address # port:/path/to/cvsroot For example: Export cvsroot =: ext: horn@166.111.55.119:/CVS/horn where ext specifies that the SSH protocol is used, and horn is the user with access to the appropriate directory of the server. You can use the-D option to specify the cvsroot value on the command line, for example, CVS-D/CVS/horn update.

When cvs_rsh specifies that the protocol used by the client to access the server uses the SSH protocol, you can set it as follows: Export cvs_rsh = SSH

Basic commands

The command line format of CVS is:

        cvs [options] command [options] filename

For details about the parameters, refer to Info CVs.

If the CVS command does not contain parameters, the current directory is always used as the operation object.

The following describes the basic commands:

Initialize the init CVS code library, which is used by the Administrator. CVS-D/CVS/horn init initializes/CVS/horn to a code base.

Import a project/module, which is used by the Administrator. After executing CVS import-M "Comments" project_name vendor_tag release_tag, all files and directories in the current directory will be imported to the/path/to/cvsroot/project_name directory. Vender_tag: developer flag release_tag: if the initial version tag-M parameter is not added, CVS automatically starts VI and requires a comment. For example, CD/home/horn/blob-2.05/CVS import blob hornworks initversion

Checkout/Co get code from the server and create the code tree CVS checkout project_name locally

Update/Up: synchronize local files to the latest version. CVs update filename does not specify a file name. CVs synchronizes files in all subdirectories of the current directory. As described earlier, update should be performed before and after the job is committed every day to ensure that the local code is always up-to-date and there is no conflict with the server code.

Commit/CI synchronize the changes to the CVS library CVS commit-M "write some comments here" file_name cvs. Many of the actions are confirmed and modified through CVS commit. Before confirming the modification, you also need to enter the modification notes to help other developers understand the reasons for the modification.

Before adding a file/directory to the project, add new_file to CVS, you must first create the file and then use CVS add to add the file. The file addition operation is only added to the code base after the CVS commit operation. For non-plain text projects such as images and Word documents, use the CVS add-kb option to import files in binary format (k indicates the extension option, and B indicates the binary file ), otherwise, the file may be damaged.

When removing a file CVS remove file_name from a project, you must physically delete a source file before using the remove command. For example, RM file_name CVS remove file_name and then commit to confirm deletion. You can also add the-F parameter to combine the two steps: CVs remmove-F file_name CVS commit-M "why delete file" CVS cannot delete directories, empty directories will be automatically ignored according to the options during update.

Log/history view modification history CVS log file_name

View differences between different versions of files in diff CVS diff-r1.3-r1.5 file_name view differences between version 1.3 and version 1.5 CVS diff file_name view differences between local and library files

Tag tag version number CVS tag release_version CVS automatically maintains the version number of each file. Each time a file is modified, its version number is automatically increased. This version cannot be used for phased release. The tag command marks a unified release version number for all files in the current directory. For example, the CD blob/CVS tag 2.1.0-hornworks tag command should be designated and used by the project owner.

When the export project is released, a CVS/directory is created in each directory of the local code tree of the source file without the CVS directory to record the corresponding information between the current directory and the CVS library. Export can export a code tree that does not contain the CVS directory. CVS export-r release project_name: Code marked as release. CVs export-D 20021023 project_name: export the latest file as of. 10.23