Партнёры:
Хостинг:
cvs - Concurrent Versions System
cvs keeps a single copy of the master sources. This copy is called the source ``repository''; it contains all the information to permit extracting previous software releases at any time based on either a symbolic revision tag, or a date in the past.
Warning: you must be careful of precisely where you place options relative to the cvs_command. The same option can mean different things depending on whether it is in the cvs_options position (to the left of a cvs command) or in the command_options position (to the right of a cvs command).
There are only two situations where you may omit cvs_command: or elicits a list of available commands, and or displays version information on cvs itself.
Use these options to control the overall cvs program:
To use the option transparently, simply place the line 'cvs -g' in your ~/.cvsrc file. Doing this is not recommended unless you firewall all your source checkouts within a private group or within a private mode 0700 directory.
The .cvsrc file lists CVS commands with a list of arguments, one command per line. For example, the following line in .cvsrc:
diff -c
will mean that the command will always be passed the -c option in addition to any other options that are specified in the command line (in this case it will have the effect of producing context sensitive diffs for all executions of ).
Global options are specified using the cvs keyword. For example, the following:
cvs -q
will mean that all commands will behave as thought he -q global option had been supplied.
1 month ago 2 hours ago 400000 seconds ago last year last Monday yesterday a fortnight ago 3/31/92 10:00:07 PST January 23, 1987 10:05pm 22:00 GMT
Some of the more useful kflags are -ko and -kb (for binary files), and -kv which is useful for an export where you wish to retain keyword information after an import at some other site.
The tag specification is ``sticky'' when you use this option with or to make your own copy of a file: cvs remembers the tag and continues to use it on future update commands, until you specify otherwise. tag can be either a symbolic or numeric tag. When a command expects a specific revision, the name of a branch is interpreted as the most recent revision on that branch. Specifying the -q global option along with the -r command option is often useful, to suppress the warning messages when the RCS file does not contain the specified tag. -r is available with the annotate, checkout, commit, diff, history, export, rdiff, rtag, and update commands. Warning: this is not the same as the overall option, which you can specify to the left of a cvs command!
If the argument to refers to an immediate sub-directory, the directory is created at the correct place in the source repository, and the necessary cvs administration files are created in your working directory. If the directory already exists in the source repository, still creates the administration files in your version of the directory. This allows you to use to add a particular directory to your private sources even if someone else created that directory after your checkout of the sources. You can do the following:
example% mkdir new_directory example% cvs add new_directory example% cvs update new_directory
An alternate approach using might be:
example% cvs update -d new_directory
(To add any available new directories to your working directory, it's probably simpler to use or
The added files are not placed in the source repository until you use to make the change permanent. Doing a on a file that was removed with the command will resurrect the file, if no command intervened.
You will have the opportunity to specify a logging message, as usual, when you use to make the new file permanent. If you'd like to have another logging message associated with just creation of the file (for example, to describe the file's purpose), you can specify it with the option to the add command.
The option specifies the default way that this file will be checked out. The argument is stored in the RCS file and can be changed with Specifying is useful for checking in binaries that shouldn't have keywords expanded.
modules are either symbolic names (themselves defined as the module in the source repository; see cvs(5)) for some collection of source directories and files, or paths to directories or files in the repository.
Depending on the modules you specify, checkout may recursively create directories and populate them with the appropriate source files. You can then edit these source files at any time (regardless of whether other software developers are editing their own copies of the sources); update them to include new changes applied by others to the source repository; or commit your work as a permanent change to the repository.
Note that checkout is used to create directories. The top-level directory created is always added to the directory where checkout is invoked, and usually has the same name as the specified module. In the case of a module alias, the created sub-directory may have a different name, but you can be sure that it will be a sub-directory, and that checkout will show the relative path leading to each file as it is extracted into your private work area (unless you specify the -Q global option).
Running on a directory that was already built by a prior checkout is also permitted, and has the same effect as specifying the -d option to the update command described below.
The options permitted with include the standard command options -P, -f, -k kflag , -l, -n, -p, -r tag, and -D date.
In addition to those, you can use these special command options with checkout:
Use the -A option to reset any sticky tags, dates, or -k options. (If you get a working file using one of the -r, -D, or -k options, cvs remembers the corresponding tag, date, or kflag and continues using it on future updates; use the -A option to make cvs forget these specifications, and retrieve the ``head'' version of the file). Does not reset sticky -k options on modified files.
The -j branch option merges the changes made between the resulting revision and the revision that it is based on (e.g., if the tag refers to a branch, cvs will merge all changes made in that branch into your working file).
With two -j options, cvs will merge in the changes between the two respective revisions. This can be used to ``remove'' a certain delta from your working file.
In addition, each -j option can contain on optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag. An example might be what tells you to do when you have just imported sources that have conflicts with local changes:
example% cvs checkout -jTAG:yesterday -jTAG module
Use the -N option with to avoid shortening module paths in your working directory. (Normally, cvs shortens paths as much as possible when you specify an explicit target directory.)
Use the -c option to copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working directory.
Use the -d dir option to create a directory called dir for the working files, instead of using the module name. Unless you also use -N, the paths created under dir will be as short as possible.
Use the -s option to display per-module status information stored with the -s option within the modules file.
If you don't specify particular files to commit, all of the files in your working current directory are examined. commit is careful to change in the repository only those files that you have really changed. By default (or if you explicitly specify the -R option), files in subdirectories are also examined and committed if they have changed; you can use the -l option to limit commit to the current directory only. Sometimes you may want to force a file to be committed even though it is unchanged; this is achieved with the -f flag, which also has the effect of disabling recursion (you can turn it back on with -R of course).
commit verifies that the selected files are up to date with the current revisions in the source repository; it will notify you, and exit without committing, if any of the specified files must be made current first with commit does not call the update command for you, but rather leaves that for you to do when the time is right.
When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs and placed in the source repository file. You can instead specify the log message on the command line with the -m option, thus suppressing the editor invocation, or use the -F option to specify that the argument file contains the log message.
The -r option can be used to commit to a particular symbolic or numeric revision. For example, to bring all your files up to the revision ``3.0'' (including those that haven't changed), you might do:
example% cvs commit -r3.0
cvs will only allow you to commit to a revision that is on the main trunk (a revision with a single dot). However, you can also commit to a branch revision (one that has an even number of dots) with the -r option. To create a branch revision, one typically use the -b option of the rtag or tag commands. Then, either checkout or update can be used to base your sources on the newly created branch. From that point on, all commit changes made within these working sources will be automatically added to a branch revision, thereby not perturbing main-line development in any way. For example, if you had to create a patch to the 1.2 version of the product, even though the 2.0 version is already under development, you might do:
example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module example% cvs checkout -rFCS1_2_Patch product_module example% cd product_module [[ hack away ]] example% cvs commit
Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like:
example% cvs tag -b EXPR1 example% cvs update -rEXPR1 [[ hack away ]] example% cvs commit
Others would simply do to work with you on the experimental change.
See for a list of supported format_options.
If you don't specify any files, diff will display differences for all those files in the current directory (and its subdirectories, unless you use the standard option -l) that differ from the corresponding revision in the source repository (i.e. files that you have changed), or that differ from the revision specified.
The only non-standard options are (write the source into directory dir) and (don't shorten module paths). These have the same meanings as the same options in
The -kv option is useful when export is used. This causes any keywords to be expanded such that an import done at some other site will not lose the keyword revision information. Other kflags may be used with and are described in co(1).
Warning: uses and in ways that conflict with the descriptions in COMMON COMMAND OPTIONS.
Several options (shown above as -report) control what kind of report is generated:
The repository argument gives a directory name (or a path to a directory) under the CVS root directory for repositories; if the directory did not exist, import creates it.
When you use import for updates to source that has been modified in your source repository (since a prior import), it will notify you of any files that conflict in the two branches of development; use to reconcile the differences, as import instructs you to do.
By default, certain file names are ignored during names associated with CVS administration, or with other common source control systems; common names for patch files, object files, archive files, and editor backup files; and other names that are usually artifacts of assorted utilities. For an up to date list of ignored file names, see the Cederqvist manual (as described in the SEE ALSO section of this manpage).
The outside source is saved in a first-level branch, by default Updates are leaves of this branch; for example, files from the first imported collection of source will be revision then files from the first imported update will be revision and so on.
At least three arguments are required. repository is needed to identify the collection of source. vendortag is a tag for the entire branch (e.g., for You must also specify at least one releasetag to uniquely identify the files at the leaves created each time you execute The releasetag should be new, not previously existing in the repository file, and uniquely identify the imported release.
One of the standard cvs command options is available: -m message. If you do not specify a logging message with -m, your editor is invoked (as with commit) to allow you to enter one.
There are three additional special options.
Use to specify that each file's time of last modification should be used for the checkin date and time.
Use to specify a first-level branch other than
Use to specify file names that should be ignored during import. You can use this option repeatedly. To avoid ignoring any files at all (even those ignored by default), specify
Note that if the software release affected is contained in more than one directory, then it may be necessary to specify the -p option to the patch command when patching the old sources, so that patch is able to find the files that are located in other directories.
The standard option flags -f, and -l are available with this command. There are also several special option flags:
If you use the -s option, no patch output is produced. Instead, a summary of the changed or added files between the two releases is sent to the standard output device. This is useful for finding out, for example, which files have changed between two dates or revisions.
If you use the -t option, a diff of the top two revisions is sent to the standard output device. This is most useful for seeing what the last change to a file was.
If you use the -u option, the patch output uses the newer ``unidiff'' format for context diffs.
You can use -c to explicitly specify the form of context diffs (which is the default), if you like.
Use to avoid these problems. This command checks that no un-committed changes are present; that you are executing it from immediately above, or inside, a cvs working directory; and that the repository recorded for your files is the same as the repository defined in the module database.
If all these conditions are true, leaves a record of its execution (attesting to your intentionally abandoning your checkout) in the cvs history log.
You can use the -d flag to request that your working copies of the source files be deleted if the release succeeds.
The files are not actually removed until you apply your changes to the repository with commit; at that point, the corresponding RCS files in the source repository are moved into the directory (also within the source repository).
This command is recursive by default, scheduling all physically removed files that it finds for removal by the next commit. Use the -l option to avoid this recursion, or just specify that actual files that you wish remove to consider.
In general, tags (often the symbolic names of software distributions) should not be removed, but the -d option is available as a means to remove completely obsolete symbolic names if necessary (as might be the case for an Alpha release, say).
will not move a tag that already exists. With the -F option, however, will re-locate any instance of symbolic_tag that already exists on that file to the new repository versions. Without the -F option, attempting to use to apply a tag that already exists on that file will produce an error message.
The -b option makes the tag a ``branch'' tag, allowing concurrent, isolated development. This is most useful for creating a patch to a previously released software distribution.
You can use the standard -r and -D options to tag only those files that already contain a certain tag. This method would be used to rename a tag: tag only the files identified by the old tag, then delete the old tag, leaving the new tag on exactly the same files as the old tag.
rtag executes recursively by default, tagging all subdirectories of modules you specify in the argument. You can restrict its operation to top-level directories with the standard -l option; or you can explicitly request recursion with -R.
The modules database can specify a program to execute whenever a tag is specified; a typical use is to send electronic mail to a group of interested parties. If you want to bypass that program, use the standard -n option.
Use the -a option to have rtag look in the for removed files that contain the specified tag. The tag is removed from these files, which makes it convenient to re-use a symbolic tag as development continues (and files get removed from the up-coming distribution).
You can also use this command to anticipate the potential impact of a on your working source directory. If you do not specify any files explicitly, reports are shown for all files that cvs has placed in your working directory. You can limit the scope of this search to the current directory itself (not its subdirectories) with the standard -l option flag; or you can explicitly request recursive status reports with the -R option.
The -v option causes the symbolic tags for the RCS file to be displayed as well.
One potentially surprising aspect of the fact that cvs tag operates on the repository is that you are tagging the checked-in revisions, which may differ from locally modified files in your working directory. If you want to avoid doing this by mistake, specify the -c option to cvs tag. If there are any locally modified files, CVS will abort with an error before it tags any files.
One use for tags is to record a ``snapshot'' of the current sources when the software freeze date of a project arrives. As bugs are fixed after the freeze date, only those changed sources that are to be part of the release need be re-tagged.
The symbolic tags are meant to permanently record which revisions of which files were used in creating a software distribution. The checkout, export and update commands allow you to extract an exact copy of a tagged release at any time in the future, regardless of whether files have been changed, added, or removed since the release was tagged.
You can use the standard -r and -D options to tag only those files that already contain a certain tag. This method would be used to rename a tag: tag only the files identified by the old tag, then delete the old tag, leaving the new tag on exactly the same files as the old tag.
Specifying the -f flag in addition to the -r or -D flags will tag those files named on the command line even if they do not contain the old tag or did not exist on the specified date.
By default (without a -r or -D flag) the versions to be tagged are supplied implicitly by the cvs records of your working files' history rather than applied explicitly.
If you use the symbolic tag you specify is deleted instead of being added. Warning: Be very certain of your ground before you delete a tag; doing this effectively discards some historical information, which may later turn out to have been valuable.
will not move a tag that already exists. With the -F option, however, will re-locate any instance of symbolic_tag that already exists on that file to the new repository versions. Without the -F option, attempting to use to apply a tag that already exists on that file will produce an error message.
The -b option makes the tag a ``branch'' tag, allowing concurrent, isolated development. This is most useful for creating a patch to a previously released software distribution.
Normally, tag executes recursively through subdirectories; you can prevent this by using the standard -l option, or specify the recursion explicitly by using -R.
update keeps you informed of its progress by printing a line for each file, prefaced with one of the characters to indicate the status of the file:
Use the -A option to reset any sticky tags, dates, or -k options. (If you get a working copy of a file by using one of the -r, -D, or -k options, cvs remembers the corresponding tag, date, or kflag and continues using it on future updates; use the -A option to make cvs forget these specifications, and retrieve the ``head'' version of the file).
The -jbranch option merges the changes made between the resulting revision and the revision that it is based on (e.g., if the tag refers to a branch, cvs will merge all changes made in that branch into your working file).
With two -j options, cvs will merge in the changes between the two respective revisions. This can be used to ``remove'' a certain delta from your working file. E.g., If the file foo.c is based on revision 1.6 and I want to remove the changes made between 1.3 and 1.5, I might do:
example% cvs update -j1.5 -j1.3 foo.c # note the order...
In addition, each -j option can contain on optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag.
-jSymbolic_Tag:Date_Specifier
Use the -d option to create any directories that exist in the repository if they're missing from the working directory. (Normally, update acts only on directories and files that were already enrolled in your working directory.) This is useful for updating directories that were created in the repository since the initial checkout; but it has an unfortunate side effect. If you deliberately avoided certain directories in the repository when you created your working directory (either through use of a module name or by listing explicitly the files and directories you wanted on the command line), then updating with -d will create those directories, which may not be what you want.
Use -I name to ignore files whose names match name (in your working directory) during the update. You can specify -I more than once on the command line to specify several files to ignore. By default, update ignores files whose names match certain patterns; for an up to date list of ignored file names, see the Cederqvist manual (as described in the SEE ALSO section of this manpage).
Use to avoid ignoring any files at all.
Use the option to overwrite locally modified files with clean copies from the repository (the modified file is saved in `.#file.revision', however).
The standard cvs command options -f, -k, -l, -P, -p, and -r are also available with update.
Files in home directories:
Files in working directories:
Files in source repositories:
For CVS updates, more information on documentation, software related to CVS, development of CVS, and more, see: http://cvs.nongnu.org
ci(1), co(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1), rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |