Source control

 
A Source Control system keeps track of all of the old versions of your files. It lets you recover old files, compare versions of file, and identify specific versions and groupings of files such as for controlled deployment.

the OpenACS reference platform and the OpenACS.org repository (where you can get patched and development code in between releases) use cvs.

This is a place to add notes about other source controls and services used by the community..

Guidelines

First READ the official cvs rules https://openacs.org/forums/message-view?message_id=185506

These rules apply whichever source control tool OpenACS is using at the time. As of this writing, we are still using CVS.

1. Don't mix bug fixes and new work
2. Don't commit code before it is tested in a clean environment (new working copy)
3. If possible, have someone else test your fix
4. Branch when necessary, don't be afraid of it (but ask OCT first)

1. Don't mix bug fixes and

• Be liberal with working copies. If you need to merge custom code into OpenACS, checkout a new working copy. Don't be stingy. Disk space is cheap. This prevents many problems by reducing accidental commits.
  • bottom line: don't mix bug fixes and new work! If you have a checkout of OpenACS you are developing some new package or feature for an existing package, and you run into a bug, fix the bug in a clean checkout of OpenACS. This is the only sane way to make sure you 1) actually fix the bug and 2) don't commit other changes that don't pertain to the bug fix.

2. Don't commit code before it is tested in clean environment

• Review your changes before committing. If possible ask someone else to look. Do a cvs -qn update to see if the commit is not changing any files you did not expect. Use cvs diff to compare your changes to the respository.
• So for committing code back to OpenACS from your local repository you should have 2 copies
  • 1) your local code
  • 2) a working copy of OpenACS HEAD
• You should make all changes in the working copy and fully test it, running automated tests and checking to make sure you did not accidentally change something or add in client specific  code that is not reusable by OpenACS.

3. If possible, have someone else test your fix

• this should be self-evident, a second pair of eyes always helps to find something you missed.
• if another person is not possible, write an automated test, in fact, write one anyway! 

4. Branch when necessary, don't be afraid of it (but ask OCT first)

• Large projects should be done on a branch. This is a pain with CVS, but it is the only sensible way to do this. Examples include any project that will span a major release cycle. It is the responsibility of the person doing the branch to keep up to date with HEAD and to merge and have the code tested. It is sensible to test in a working copy BEFORE committing the code.

Ideas

Here is my heretical idea. I think we must have another branch. Here is how it would work.

1) developer has a working copy.

2) develop commits code to HEAD

3) code is merged to testing branch

4) code is tested

5) code is moved to release branch

Yes, this is extra work. I believe it is worth it. It is a serious pain with CVS. We started using svnmerge.py for Subversion on our private repository and I saw immediate improvements in process. In this case I think having a well defined process AND tools that facilitate the process are key. OpenACS lacks a well defined process, discipline, and tools to facilitate the process. I believe we need to work harder to define this process and I would like to collaborate with the community on this.