Synopsis: commit [-lnRf] [-m 'log_message' | -F file] [-r revision] [files...]
Requires: working directory, repository.
Changes: repository.
Synonym: ci
Use commit when you want to incorporate changes from your working source files into the source repository.
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.
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 update (the section called “update--Bring work tree in sync with repository”). 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 (the section called “The modules file”, and the section called “Loginfo”) and placed in the
rcs file inside the repository. This log message can be retrieved with
the log command; see the section called “log--Print out log information for files”. You can
specify the log message on the command line with the -m
message option, and thus avoid the editor
invocation, or use the -F file
option to specify that the argument file contains the log
message.
These standard options are supported by commit (the section called “Common command options”, for a complete description of them):
Assume all datestamps are different and send all files to the server for checking.
Local; run only in current working directory.
Do not run any module program.
Commit directories recursively. This is on by default.
commit also supports these options:
fileRead the log message from file, instead
of invoking an editor.
Note that this is not the standard behavior of the -f option as defined in the section called “Common command options”.
Force cvsnt to commit a new revision even if you haven't
made any changes to the file. If the current revision of
file is 1.7, then the following two commands
are equivalent:
$ cvs commit -ffile$ cvs commit -r 1.8file
The -f option disables recursion (i.e., it implies -l). To force cvsnt to commit a new revision for all files in all subdirectories, you must use -f -R.
This command is also used when changing -k expansion options. Unless -f is specified modified options will not be propogated back to the server.
messageUse message as the log message, instead
of invoking an editor.
Check for a valid edit on the file before committing. See 'cvs edit'.
bugidOnly commit files that have been edited and marked with
bug bugid.
bugidMark committed files as belonging to bug
bugid.
Keep files edited after commit - supresses the automatic unedit that normally follows a commit.
Attempt to move branches rather than create branch revisions where possible. Where a branch has no revisions, this option will compare what you are trying to commit with the parent branch head, and if they are identical it will move the branch rather than create a new revision.
This option has detrimental affects on reproducability, for example:
In branch A, a developer is working with files a (version 1.1) and b (version 1.1.2.1). He merges from HEAD, then commits using this option, moving the branch A in file a to version 1.2, and committing a new file b version 1.1.2.2
Meanwhile manager B notices that that branch A is now broken, and asks the developer to fix it. The developer knows that the revsion 1.1.2.1 file works, so he wants to test with the older version. He can't. Since the environment that the older file was written in no longer exists (as the branchpoint has moved), it's impossible to roll back.
For this reason it is recommended that this option only be used where absolutely necessary, and on unrelated files only.
You can commit to a branch revision (one that has an even number of dots) with the -r option. To create a branch revision, use the -b option of the rtag or tag commands (Chapter 6, Branching and merging). 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 disturbing 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:
$ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module $ cvs checkout -r FCS1_2_Patch product_module $ cd product_module [[ hack away ]] $ cvs commit
This works automatically since the -r option is sticky.
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 cvsnt conflict resolution. The scenario might look like:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit
The update command will make the -r EXPR1 option sticky on all files. Note that your changes to the files will never be removed by the update command. The commit will automatically commit to the correct branch, because the -r is sticky.
To work with you on the experimental change, others would simply do
$ cvs checkout -r EXPR1 whatever_module