Developer Manual
Home
News
Tutorials
User Manual
Reference Manual
Developer Manual
Downloads
Forums
Team Members
Future Work
FAQ
Links

Revision control

Revision control is by SVN. Please check in changes as soon as they are stable, e.g. at least by the end of each significant workday. Conversely, be sure to update your checked out code before doing any new work. The goal is to make sure that all developers are always working with the latest code.

Every SVN commit must include an informative log message, summarizing the items changed in easily understandable terms, and avoiding pejorative language (i.e. comments like "Lord only knows what idiot coded it that way!"). If possible (e.g. when adding a feature or fixing a bug), try to link the commit log message to one of the sf.net tracker IDs (and vice versa).

If so many items were changed that any single log message would have to be very general (e.g. "Misc changes to many files"), then please check in smaller groups of files, each with a meaningful log message. Using smaller, meaningful chunks also makes debugging much easier later, allowing the source of a new bug to be tracked down to a small, understandable set of changes. Conversely, if the same trivial changes were made to a large group of files, please check in all of those at once, with the same log message, so that it will be clear that they go together.

Ideally, each commit should reflect a single purpose (e.g. addition of a new feature or a bug fix); each commit increments Topographica's version number, and the log message applies to that whole version. Therefore, when committing files, please do it in the appropriate order and grouping so that the code works at every time in the SVN repository history. That is, if you change several files, adding a function to one file and then calling it in another, consider if you should check in the file with the new function first, or if you should check in the two files together. In this situation you should certainly not check in the file that calls the function before checking in the file containing the function. In this opposite order, the repository would temporarily be in a state where it could not supply working code. Even if you know no one else is working at that time, such gaps make it much more difficult to debug using the SVN revision history, because they make it impractical to roll back history one change at a time to try to find the source of a bug.

When making and checking in particularly extensive changes, please keep refactoring completely separate from new features whenever possible. That is, if you have to change or clean up a lot of old code in order to add a new feature, follow something like this procedure:

  svn commit .	  # Commit all outstanding edits
  make tests	  # Verify that things work when you start
  emacs		  # Refactor old code, not changing behavior at all
  make tests      # Verify that nothing has been broken
  svn diff        # Will have many widespread changes
  svn commit -m    "No visible changes" .
  emacs		  # Add new feature and new test for it
  make tests      # See if tests still work, fixing if necessary
  svn diff	  # Short list: only the new code
  svn commit -m    "Added feature Y" .
That way nearly all of the lines and files you changed can be tested thoroughly using the existing test suite as-is, and any tests added can be tested equally well on both the old and new code. Then the few lines implementing the new feature can be added and debugged on their own, so that it will be very simple to see whether the new feature was the source of a bug, or whether it was all those other changes that shouldn't have changed anything.

Revision info

Every readable file (i.e. text, source code, html, etc.) should include an $Id:$ tag so that the SVN revision information will be visible immediately, even in files outside of the SVN repository.

For text files, the Id: tag should be placed near the top, surrounded by dollar signs, on a line by itself. Near the bottom is also acceptable, but not preferred. See the top of the README.txt file for an example; SVN fills in all but the letters "Id:" and the dollar signs.

For Python files, the Id: tag should be placed at the end of the Python doc string for that module, surrounded by dollar signs, on a line by itself.

If you include the following in your ~/.subversion/config file, these things will be done automatically for you:

# ... (other content you have already)
[auto-props]
# ... (other content you have already)
Makefile = svn:eol-style=native;svn:keywords="Author Date Id Revision"
*.ty = svn:eol-style=native;svn:keywords="Author Date Id Revision"
*.py = svn:eol-style=native;svn:keywords="Author Date Id Revision"
*.txt = svn:eol-style=native;svn:keywords="Author Date Id Revision"
*.diff = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg

Hosted by: SourceForge Logo James A. Bednar (jbednar@inf.ed.ac.uk) Last update: Thu Feb 21 15:17:03 UTC 2008.