| 5.4. Using SVN |
| Prev | Chapter 5. Developer Guidelines | Next |
|---|
This section describes things that are generally applicable when using SVN; guidelines that are more specific to particular tasks or uses are described in the other sections.
Check in early, check in often. When you have made a change that works, check it in. Check in separate changes in separate commits (as much as possible). Don't be shy to check in work-in-progress, so long as it is minimally functional, or at least compilable without errors.
Use meaningful commit messages. Explain what bug the commit fixes, or what features it adds. Don't be too concise: "fixed typo" is too short; "fixed Task# 2432" or "fixed typo in function name" is OK. The aim is to make it easier to find the desired change easily from just the commit messages.
The converse of this is including too much information. SVN automatically maintains information like the date and time of the commit, who made the commit, what code was changed, etc. You don't need to include it in the commit message yourself.
If in doubt, lay down a
tag. Tags are useful for pinning down a particular
version of the code, e.g. one that is being run in service, or just
before a big change or import. They are also used to identify
branches. Tag names should be short and meaningful, like variable
names. For example, virtuemart-20051222,
pre-new-virtuemart,
fanf-patches, corresponding to the uses mentioned
above. Tags should be commented in the modules file.