(Created page with "{{TOCright}} This is a very short introduction to CVS, the Concurrent Versions System. Further information should be obtained from the official sources and manuals. === Structur...") |
(→Committing local changes) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
This is a very short introduction to CVS, the Concurrent Versions System. Further information should be obtained from the official sources and manuals. | This is a very short introduction to CVS, the Concurrent Versions System. Further information should be obtained from the official sources and manuals. | ||
| − | + | == Structure == | |
[[Image:CVSInteractions.png]] | [[Image:CVSInteractions.png]] | ||
CVS defines a source repository that will be the hub for all the entities involved in a project. Each entity will request a module (in CVS parlance, a directory belonging to a tree controlled by the repository) to work on locally. Then, each local copy may be the object of several editing and management operations for keeping it in sync with the repository. Since changes are concurrent, compatibility problems may arise during the life of a local copy, until it again becomes synchronized with the central repository (see image). | CVS defines a source repository that will be the hub for all the entities involved in a project. Each entity will request a module (in CVS parlance, a directory belonging to a tree controlled by the repository) to work on locally. Then, each local copy may be the object of several editing and management operations for keeping it in sync with the repository. Since changes are concurrent, compatibility problems may arise during the life of a local copy, until it again becomes synchronized with the central repository (see image). | ||
| Line 9: | Line 9: | ||
The repository's location may be specified directly as an option to the "cvs" command: | The repository's location may be specified directly as an option to the "cvs" command: | ||
| − | < | + | <source lang="shell"> |
cvs -d /root/of/the/cvs/repository some-cvs-subcommand | cvs -d /root/of/the/cvs/repository some-cvs-subcommand | ||
| − | </ | + | </source> |
Or it may be read from the <tt>CVSROOT</tt> environment variable (defined, for instance, in the shell's configuration file): | Or it may be read from the <tt>CVSROOT</tt> environment variable (defined, for instance, in the shell's configuration file): | ||
| − | < | + | <source lang="shell"> |
export CVSROOT=/root/of/the/cvs/repository | export CVSROOT=/root/of/the/cvs/repository | ||
cvs some-cvs-subcommand | cvs some-cvs-subcommand | ||
| − | </ | + | </source> |
Various modes of access are possible: local (i.e., direct access to the CVS repository's file system exists) or remote (otherwise). Remote access may be done through CVS's own protocol (pserver), but this is insecure. Another remote access method is the one specified by the <tt>CVS_RSH</tt> command (which defines the method for extended access methods). A common definition for this variable (in fact, the default in some systems) is "ssh": | Various modes of access are possible: local (i.e., direct access to the CVS repository's file system exists) or remote (otherwise). Remote access may be done through CVS's own protocol (pserver), but this is insecure. Another remote access method is the one specified by the <tt>CVS_RSH</tt> command (which defines the method for extended access methods). A common definition for this variable (in fact, the default in some systems) is "ssh": | ||
| − | < | + | <source lang="shell"> |
export CVS_RSH=ssh | export CVS_RSH=ssh | ||
| − | </ | + | </source> |
The CVSROOT variable now can be written as: | The CVSROOT variable now can be written as: | ||
| − | < | + | <source lang="shell"> |
export CVSROOT=:ext:username@somemachine.somedomain:/root/of/the/remote/cvs/repository | export CVSROOT=:ext:username@somemachine.somedomain:/root/of/the/remote/cvs/repository | ||
| − | </ | + | </source> |
The repository manages files by giving them revision numbers. Special tags may be used to group various files in various satges of evolution, creating snapshots of the repository's state for further reference. The default tag (corresponding to the most recent versions) is called HEAD. | The repository manages files by giving them revision numbers. Special tags may be used to group various files in various satges of evolution, creating snapshots of the repository's state for further reference. The default tag (corresponding to the most recent versions) is called HEAD. | ||
| Line 30: | Line 30: | ||
Interaction with the repository is done by first performing a "check-out" operation (for obtaining a local copy) and, then, through a cycle of "update"/"commit" operations. A "release" operation may or may not be needed (when the local copy is no longer needed). | Interaction with the repository is done by first performing a "check-out" operation (for obtaining a local copy) and, then, through a cycle of "update"/"commit" operations. A "release" operation may or may not be needed (when the local copy is no longer needed). | ||
| − | + | == Creating the repository == | |
The following command is almost never used and is presented here just for reference (we assume that the <tt>CVSROOT</tt> variable has been defined): | The following command is almost never used and is presented here just for reference (we assume that the <tt>CVSROOT</tt> variable has been defined): | ||
| − | < | + | <source lang="shell"> |
cvs init | cvs init | ||
| − | </ | + | </source> |
This command creates a special control module (in the directory specified by the <tt>CVSROOT</tt> variable) called <tt>CVSROOT</tt>. This module will control how CVS manages each of the projects and files in the repository. | This command creates a special control module (in the directory specified by the <tt>CVSROOT</tt> variable) called <tt>CVSROOT</tt>. This module will control how CVS manages each of the projects and files in the repository. | ||
| − | + | == Creating a new module == | |
A new CVS module may be created from a source tree (assumed outside CVS control) as explained below. We assume that the future module contents are in the <tt>/some/directory/to/be/imported</tt> directory. | A new CVS module may be created from a source tree (assumed outside CVS control) as explained below. We assume that the future module contents are in the <tt>/some/directory/to/be/imported</tt> directory. | ||
| − | < | + | <source lang="shell"> |
cd /some/directory/to/be/imported | cd /some/directory/to/be/imported | ||
cvs import module-name vendor-tag initial-release-tag | cvs import module-name vendor-tag initial-release-tag | ||
| − | </ | + | </source> |
Where ''module-name'' is the name of the new module (e.g. the project's name), ''vendor-tag'' is a label (e.g. a nickname of an acronym of the author or context), and ''initial-release-tag'' is the initial tag (e.g. "initial"). | Where ''module-name'' is the name of the new module (e.g. the project's name), ''vendor-tag'' is a label (e.g. a nickname of an acronym of the author or context), and ''initial-release-tag'' is the initial tag (e.g. "initial"). | ||
| Line 53: | Line 53: | ||
'''If the module/project is already in the repository (even if it is empty), no import operation is needed (see the "add" operation below).''' | '''If the module/project is already in the repository (even if it is empty), no import operation is needed (see the "add" operation below).''' | ||
| − | + | == Checking out == | |
The check out command creates a local copy of a module in the repository: | The check out command creates a local copy of a module in the repository: | ||
| Line 59: | Line 59: | ||
cvs co module-name | cvs co module-name | ||
| − | + | == Updating a local copy == | |
The update operation synchronizes a local copy with the contents of the module on the repository. The synchronization process may cause new files to be downloaded into the local copy, obsolete files to be removed and existing files to be changed. Of course, the process may run into difficulties if the local copy and the information coming from the repository cannot be merged without conflicts. | The update operation synchronizes a local copy with the contents of the module on the repository. The synchronization process may cause new files to be downloaded into the local copy, obsolete files to be removed and existing files to be changed. Of course, the process may run into difficulties if the local copy and the information coming from the repository cannot be merged without conflicts. | ||
| Line 69: | Line 69: | ||
When solving a conflict, the user must first select the version to keep in the local copy and only then proceed to committing local changes. | When solving a conflict, the user must first select the version to keep in the local copy and only then proceed to committing local changes. | ||
| − | + | == Adding a local file == | |
If, during the life of a module, a new file is added to the project, then the local file must be added to the repository. This is done by the following command: | If, during the life of a module, a new file is added to the project, then the local file must be added to the repository. This is done by the following command: | ||
| Line 79: | Line 79: | ||
Local directories must be added before their contents may be added. Adding a directory creates a local CVS subdirectory for keeping information about its contents. | Local directories must be added before their contents may be added. Adding a directory creates a local CVS subdirectory for keeping information about its contents. | ||
| − | + | == Removing a local file == | |
First and foremost: the CVS repository NEVER removes any files. This is because, even if a file becomes obsolete, there were past versions of the project in which the file exists and it must be possible to recreate it. Nevertheless, it is possible to mark it as deleted, so that it no longer appears in newer versions. | First and foremost: the CVS repository NEVER removes any files. This is because, even if a file becomes obsolete, there were past versions of the project in which the file exists and it must be possible to recreate it. Nevertheless, it is possible to mark it as deleted, so that it no longer appears in newer versions. | ||
| Line 89: | Line 89: | ||
Note that CVS complains if the file still exists (this means that, for the previous command to work, the file must first be removed). | Note that CVS complains if the file still exists (this means that, for the previous command to work, the file must first be removed). | ||
| − | + | == Committing local changes == | |
The commit operation is, arguably, the most important, since it is the one that changes the repository's contents and makes the project evolve: | The commit operation is, arguably, the most important, since it is the one that changes the repository's contents and makes the project evolve: | ||
| − | cvs commit | + | cvs commit -m "Message describing commit operation" |
The commit operation allows the user to input a message that will be inserted in the log of changes made to the project. The commit operation is, by default, recursive and allows a different log message to be registered for each local directory in the project tree. | The commit operation allows the user to input a message that will be inserted in the log of changes made to the project. The commit operation is, by default, recursive and allows a different log message to be registered for each local directory in the project tree. | ||
| − | === Other CVS commands | + | '''Note that if you omit the -m option, a text editor will open to input the message (the specific text editor will depend on the environment and may be one you are unfamiliar with). <font color="brown">Aborting the text editor will also abort the commit.</font> Hence, use of the -m option is strongly recommended." |
| + | |||
| + | == Other CVS commands == | ||
In addition to the above basic commands, other are available, for instance, for tagging revisions and inspecting the repository. Further information may be obtained in the manual: | In addition to the above basic commands, other are available, for instance, for tagging revisions and inspecting the repository. Further information may be obtained in the manual: | ||
man cvs | man cvs | ||
info cvs | info cvs | ||
This is a very short introduction to CVS, the Concurrent Versions System. Further information should be obtained from the official sources and manuals.
File:CVSInteractions.png CVS defines a source repository that will be the hub for all the entities involved in a project. Each entity will request a module (in CVS parlance, a directory belonging to a tree controlled by the repository) to work on locally. Then, each local copy may be the object of several editing and management operations for keeping it in sync with the repository. Since changes are concurrent, compatibility problems may arise during the life of a local copy, until it again becomes synchronized with the central repository (see image).
The first contact with CVS may depend on the specific project and participants: the repository and/or the project may not yet exist (and have to be created), or they may both already exist (in which case, only check-out, update, and commit operations are performed).
The repository's location may be specified directly as an option to the "cvs" command:
cvs -d /root/of/the/cvs/repository some-cvs-subcommand
Or it may be read from the CVSROOT environment variable (defined, for instance, in the shell's configuration file):
export CVSROOT=/root/of/the/cvs/repository
cvs some-cvs-subcommand
Various modes of access are possible: local (i.e., direct access to the CVS repository's file system exists) or remote (otherwise). Remote access may be done through CVS's own protocol (pserver), but this is insecure. Another remote access method is the one specified by the CVS_RSH command (which defines the method for extended access methods). A common definition for this variable (in fact, the default in some systems) is "ssh":
export CVS_RSH=ssh
The CVSROOT variable now can be written as:
export CVSROOT=:ext:username@somemachine.somedomain:/root/of/the/remote/cvs/repository
The repository manages files by giving them revision numbers. Special tags may be used to group various files in various satges of evolution, creating snapshots of the repository's state for further reference. The default tag (corresponding to the most recent versions) is called HEAD.
Interaction with the repository is done by first performing a "check-out" operation (for obtaining a local copy) and, then, through a cycle of "update"/"commit" operations. A "release" operation may or may not be needed (when the local copy is no longer needed).
The following command is almost never used and is presented here just for reference (we assume that the CVSROOT variable has been defined):
cvs init
This command creates a special control module (in the directory specified by the CVSROOT variable) called CVSROOT. This module will control how CVS manages each of the projects and files in the repository.
A new CVS module may be created from a source tree (assumed outside CVS control) as explained below. We assume that the future module contents are in the /some/directory/to/be/imported directory.
cd /some/directory/to/be/imported
cvs import module-name vendor-tag initial-release-tag
Where module-name is the name of the new module (e.g. the project's name), vendor-tag is a label (e.g. a nickname of an acronym of the author or context), and initial-release-tag is the initial tag (e.g. "initial").
Note that the import operation does not automatically put the imported contents under CVS control: it is still necessary to check them out from the repository. Also, note that the import operation is recursive and that executing it without care may result in uploading trash (i.e., unwanted material) into the repository: ensure that the command is given inside the directory to be imported (as shown in the example).
If the module/project is already in the repository (even if it is empty), no import operation is needed (see the "add" operation below).
The check out command creates a local copy of a module in the repository:
cvs co module-name
The update operation synchronizes a local copy with the contents of the module on the repository. The synchronization process may cause new files to be downloaded into the local copy, obsolete files to be removed and existing files to be changed. Of course, the process may run into difficulties if the local copy and the information coming from the repository cannot be merged without conflicts.
cvs update
CVS tells the user about the state of the update process by prefixing each file name (in the log of its actions) with a single character: U (new file coming from the repository), P (local file patched to reflect changes in the repository), R (local file scheduled for removal, but still exists in the corresponding repository revision), A (local file scheduled for addition, but not yet commited), C (a conflict was detected and marked: manual intervention is needed), ? (unknown local file). Other messages may also be given (for instance, telling about the removal of local files).
When solving a conflict, the user must first select the version to keep in the local copy and only then proceed to committing local changes.
If, during the life of a module, a new file is added to the project, then the local file must be added to the repository. This is done by the following command:
cvs add name-of-local-file
Note that the command does not change the repository (it only marks the file for addition at the next commit operation).
Local directories must be added before their contents may be added. Adding a directory creates a local CVS subdirectory for keeping information about its contents.
First and foremost: the CVS repository NEVER removes any files. This is because, even if a file becomes obsolete, there were past versions of the project in which the file exists and it must be possible to recreate it. Nevertheless, it is possible to mark it as deleted, so that it no longer appears in newer versions.
The command to schedule a file removal is:
cvs remove name-of-local-file
Note that CVS complains if the file still exists (this means that, for the previous command to work, the file must first be removed).
The commit operation is, arguably, the most important, since it is the one that changes the repository's contents and makes the project evolve:
cvs commit -m "Message describing commit operation"
The commit operation allows the user to input a message that will be inserted in the log of changes made to the project. The commit operation is, by default, recursive and allows a different log message to be registered for each local directory in the project tree.
Note that if you omit the -m option, a text editor will open to input the message (the specific text editor will depend on the environment and may be one you are unfamiliar with). Aborting the text editor will also abort the commit. Hence, use of the -m option is strongly recommended."
In addition to the above basic commands, other are available, for instance, for tagging revisions and inspecting the repository. Further information may be obtained in the manual:
man cvs info cvs