 | The commit command may take some time to finish, especially if it is running over a slow network connection. It is not wise to try to abort it. |
If you want to make your changes to a package visible to the other developers, you must commit them back to the version control system. Before attempting that you should contact the package coordinator--the person responsible for that package--to make sure he or she agrees with your changes and approves them for inclusion into the package. You should also make sure you have the permissions to commit changes into the package in question, and that quality criterias of your project are fulfilled. For example, your project may require the code to compile on at least one platform and to conform to style rules before you can commit anything in. Please read your project's development policy documents to find out more about these matters. Whatever your project's policies are, try hard not to commit in code that fails to compile--test it at least one on platform first. Committing in bad code will be a major inconvenience to your fellow developers.
Once these have been taken care of, make sure your code represents the latest changes to the code. This is important because somebody else might have committed in changes since you checked out or updated your copy the last time. You can determine what changes would happen by executing the following command:
$ cvs -n update -A |
If this looks safe, you can drop the -n option and go update your local copy. You may need to repeat the command several times if it encounters errors. However, if the output of the command above looked suspicious and you want to know more the differences, use the diff command like this:
$ cvs diff -ur HEAD file.cxx |
You may, of course, just proceed to execute the update command the first time around without the -n option if you believe that it will do no harm. In any case, if update reports conflicts, you will need to resolve them by hand. The conflict regions will be marked by the command as explained in the CVS manual. Once you have resolved the conflicts, you should retest the software again to make sure this round did not introduce any new errors. Note that if the package is under heavy development, new changes may be committed in while you trying to deal with another set of conflicts.
When you are ready to intergrate your changes back to CVS, do so with the commit command like the one given below. If you omit the -m option, CVS will prompt for the comment message by starting an editor for you to type it in.[1]
$ cvs commit -m 'why and how' |
| The commit command may take some time to finish, especially if it is running over a slow network connection. It is not wise to try to abort it. |
| [1] | If the package in question is using a ChangeLog file, be sure to update it before committing the changes. If the ChangeLog is as comprehensive as it should be, the commit comment can simply become ``See ChangeLog''. |
| [1] | The actual task of copying can take place through the version control system, and is most likely the safest and easiest way of doing it. |
| [2] | On Windows NT they will just have to copy the files. |
| [3] | Note that the release will not freeze a release that has absolute paths in any use directive. Such a PACKAGE file should never be committed into the version control system. |
| [4] | When the problems manifest at source level, the compiler will barf and you will just have to go and fix the problems. It is the binary interface changes that are tricky. |