Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "DSDP/MTJ/Proposal for Code Checkin"
(Initial data) |
m (Add labels to links) |
||
| Line 1: | Line 1: | ||
| − | In addition to all of the requirements for code checkin in the Eclipse process [http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines] we should follow the following addtional guidelines. | + | In addition to all of the requirements for code checkin in the Eclipse process [http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines Development Conventions and Guidelines] we should follow the following addtional guidelines. |
# All code checkins should have a bug as a reference for the code change. An exception for small spelling or formatting changes is allowed. | # All code checkins should have a bug as a reference for the code change. An exception for small spelling or formatting changes is allowed. | ||
| Line 5: | Line 5: | ||
# All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx. " | # All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx. " | ||
| − | Look at [http://www.eclipse.org/dsdp/tm/development/committer_howto.php] | + | Look at [http://www.eclipse.org/dsdp/tm/development/committer_howto.php TM Project Committer How To Checkin] |
Revision as of 12:58, 27 September 2006
In addition to all of the requirements for code checkin in the Eclipse process Development Conventions and Guidelines we should follow the following addtional guidelines.
- All code checkins should have a bug as a reference for the code change. An exception for small spelling or formatting changes is allowed.
- All checkins should have comments attached to the checkin when it is committed to the CVS archive.
- All checkins should include the bug number at the beginning of the checkin comment. For example, prefix the comment with "Bug xxxxx. "