Added by Chris Holmes, last edited by Chris Holmes on Oct 24, 2006

Labels

 
(None)

We highly recommend that everyone read the subversion book as the definitive how-to.

Past that we have a few recommendations for GeoServer.

Atomic commits

Each commit should be about one general 'thing'. This way if something goes wrong you can roll back that one 'thing', instead of being forced to do it along with the good code you put on the same commit. For some code this can involve a number of classes - we're not saying only commit one class at a time. But only commit one feature or bug fix at a time.

Commit comments.

When committing code the -m tag allows you to specify a message. Please make use of this with an informative message about the code you are committing. It helps out immensely, especially if a bug happens to be introduced with the commit, so others can know what the commit intended to do. Make a comment for every commit, and try to use complete, useful sentences.

Record the revision number when closing bugs

In JIRA, when you close a bug you should note the svn revision number of the fix or fixes. We keep a set form for this, using 'r' followed by the revision number

r4325

Early and often

The first is that we recommend you to commit early and often. There are limits to this, but if you're on your own branch than feel free to commit quite often. If you are on trunk it's definitely useful to put in your code often so others know what you're working on. But be sure you're not breaking the build. And if you're doing hacky things that you're going to fix later, then please comment in the code and on the revision that it's a hack to get things working, so others don't do a code review.

Powered by a free Atlassian Confluence Open Source Project License granted to GeoServer . Evaluate Confluence today.

GeoServer wiki is hosted by OpenGeo - Contact Administrators