Blog

There are many great reasons to use a Source Control Management (SCM) system. If you are looking to get involved with an Open Source project or manage small and large projects of your own, you are going to need to know how to use a SCM.

This process works well for a large group of developers on a large code project, but a single developer can also benefit from using a SCM. The big benefit is an archive of all code changes over time so you can revert and compare changes. This will keep a whole history of the project in a timeline so we can pinpoint any problems that may arise.

The conventions we use are very standard in the Plone and Subversion communities. The folks over at CollabNet have put together a great list of best practices.

If you were to ask another Plone consulting company that utilizes the community best practices to help you with your code, they would be up and running in no time since we have followed these best practices. Plus, any new developers your team would bring on would benefit from the quick spin up due to the use of subversion and buildout.

Another good reason to use Subversion is that is provides some accountability for code changes. We can track who changed the code down to the line. This allows for a more orderly management of the code and helps reduce the chaos of sharing changes back and forth. That will eliminate knowing who has what code and what environment is running what version of the code too.

When working on larger features that might introduce instability for other developers is the time to leverage the power of branching. Being able to branch for larger features allows you as a developer to work and commit code without breaking other developers checkouts. Doing this allows you to continue the best practices of committing often. Maintenance branches also allow you to release small fixes while larger development is still moving forward. In either of these cases, once the development is complete you can just merge or reintegrate your changes to the trunk.

When working on projects it is very important to do releases from tags and to use branches and the trunk to collaborate. This will lead to more consistent releases and the ability to more easily roll back incase of a larger regression that isn't caught in time.