Teamwork and Subversion

I spent all of last summer at my internship with Indeed Inc (http://www.indeed.com) working with others on projects using subversion. Everyone taking this class is fortunate to be given a head start in using source control. Collaborating on the projects I did would have been near impossible without subversion.

I started out using subversion commands in the terminal, but eventually moved on to using it in Eclipse. The graphical interface provided by subclipse, the Eclipse plugin that enables subversion, is vastly superior to working in a terminal. Adam McElwee has posted a tutorial on getting subclipse working in windows here... check it out if you are interested.

When collaborating with someone on a project using subversion, make sure that you both communicate with each other. If you decide to work on one class or method, make sure the other person is aware of this and not working in the same lines of code. If you both want to work on the same piece of code, pair programming is by far the best choice. When conflicting changes are sent into the project repository, subversion does it best to merge them into one file on its own. However, if the merge doesn't go so well the resulting manual clean-up can be a real pain. By staying aware of what your partner(s) is working on, and letting them know when you are planning to check in changes, this can always be avoided.

A good habit to get into is looking over your changes before submitting a new revision. At the terminal this can be accomplished by using the 'svn st' command and the 'svn diff' command. To look at specific files, use 'svn diff filename'. Subclipse provides excellent tools for accomplishing this. The version of the file in the repository and your version are put side by side and changes are clearly marked. As the size of the projects you work on get larger and larger it will become easier to let little unessecary changes slip through. Sometimes it can be as simple as an extra newline or too many tab spaces (which can break whatever coding convention you are your teammates choose to follow), or a wrongly named method that didn't get changed to what it was supposed to be. Never blindly submit changes, this will make things much easier for you and your teammates.

One final thought: Always keep a working copy of code in the respository. If you make some changes through refactoring or try to add some new functionality and unit tests that passed before start failing, don't submit the changes until you have everything working again. If you upload broken code, then when everyone else does an update their code will break too.

p.s. Here's a link to a blog post about one of the software projects I worked on while at Indeed. A lot of the important things we are learning in this class right now like source control, working as a team and refactoring I learned while working on this project.