An often-posed question is when you should commit your changes. Some people prefer to commit every night before they go to home. Some people commit when they feel like it and remember. However, probably the best way to commit is to make the commit when you have finished a feature.

A feature could be a new JSP page, a new UI component, or whatever - something that adds to the functionality of the system.

Commiting one feature at a time is a good thing because it keeps your own desk organised. The risk of breaking the build is also less. Writing good ChangeLog entries is also easier.

Commit a feature to keep the code organised.

Fixing bugs.#

If you are working on a feature and someone comes in with an important bug, it's probably a good idea to check out a fresh copy from the repository, fix the bug, then commit that tree back to the repository and return to your original tree. This so that you wouldn't accidentally commit the changes you've already made to your usual tree for that new feature.

Reformatting code.#

Sometimes you need to reformat the code (say, because someone has been using tabs instead of spaces). Commiting this file into the repository will cause lots of apparent changes, since most version control systems function on a per-line basis.

However, if you make any other additional changes (such as fixing bugs), the changes you made will be hidden by the fact that your line has now spaces instead of tabs when you take a "cvs diff", making it impossible for someone to figure out what happened.

When you reformat code, commit the reformatted version before you make any other changes.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-1) was last changed on 27-Jul-2001 12:54 by UnknownAuthor