Section 13.1. SVN in Different Developers Workflows

13.1. SVN in Different Developers' Workflows

To start, let's take a look at the developer's daily workflow, and how Subversion fits into that process. Of course, every developer's workflow is different, and depends largely on a combination of each developer's work habits and the work environment; however, there are plenty of commonalities that we can examine, and those commonalities tend to fall into different developer types. Of course, no individual developer fits a stereotype, but for the sake of illustration, I've broken the discussion down into six archetypal developers. For each one, I've taken a look at how Subversion might fit into that developer's workflow (of course, project policies could radically alter each archetype's workflow).

13.1.1. The Methodical Programmer

The methodical programmer is the diligent developer who sits at his desk quietly and steadily churns out line after line of clean, well-documented code. In a typical day, he may come in to the office, get a cup of coffee, then sit down at his desk and do an svn update. After checking his e-mail, he will see what was updated in his working copy and test any changes to make sure they didn't affect anything he was working on.

After the methodical programmer is up to speed with the changes, and certain that everything is working properly, he will get a list of tasks for the day and begin working his way through them. For each task, he will do the following.

1. Make a branch in his own private branches directory, for implementing the task.

2. Use svn switch to switch the appropriate sections of his working copy of /TRunk over to that branch.

3. Implement the task, testing and committing after each distinct, testable change.

4. When the task is tested and complete, he will use svn switch to go back to the trunk, followed by an svn merge.

5. With the task merged into the trunk, he will do an svn update and thoroughly test the feature with any new changes.

6. The task now complete, he will commit with a detailed log message and move on to the next task on his list.

The methodical programmer is also very exacting with all of his work, and everything is done in small chunks with detailed documentation (comments, logs, and so on) at every step of the way. By using small, distinct changes for each commit, he allows himself to take maximum advantage of Subversion's merge system. If a change ever needs to be removed, he will also find merge useful, because his detailed documentation allows him to pinpoint exactly which revisions contain the change (and because each revision is a single change, svn merge can be used).

At the end of the day, the methodical programmer makes sure that all of his work has been committed to the repository, and uses svn info to make sure that every part of the working copy has been switched back to the trunk (wouldn't want to forget and accidentally commit work to the wrong place, or miss an important update). Then, he makes a list of the tasks that need to be completed the next day, before logging everything off and packing up for the day.

13.1.2. The Collaborator

The collaborator works in a team environment and shares her work frequently with others as she goes along. When she gets into work in the mornings, she first spends a few minutes chatting with her coworkers while she sips her morning latte, to catch up on what everyone else is working on. Then, she gets together with her pair-programming partner, and they discuss the day's tasks.

With a rough plan for the day put together, the collaborator and her programming partner begin implementing the days tasks. Individual tasks tend to flow together in a much more fluid manner than the rigid separation of tasks that the methodical programmer used, and branches are less commonly used. In general, the collaborator's workflow for tasks runs something like this:

1. She updates frequently to get the latest changes from the other developers on the project, discusses those changes with them over e-mail or instant messaging (or occasionally by shouting across the room) if any clarification is necessary, and tests her changes thoroughly with any new updates when they occur.

2. She and her programming partner implement tasks in their working copy, and commit frequently, as new bits of features are tested. For experimental changes, she may create a branch to avoid breaking the project build for other developers.

3. When one task is complete, she moves on to the next, but this process tends to be somewhat fluid, with one task flowing into the next. There often are no clear breaks between broad tasks.

The collaborator also makes heavy use of tools that integrate her work with that of her coworkers. For instance, she is very "at home" in an environment where a site such as Trac (Section 13.3.2, "Automating Interaction with Issue Tracking") has been implemented. When she has access to Trac, she makes heavy use of it to document all of her work for others. She also keeps running RSS feeds of commits to each project or project component that she is interested in displayed on her secondary display at all times. Any new designs or potential changes to the structure of the application under development are drawn up and described using the Trac wiki, or some other collaborative tool that allows her ideas to be viewed and commented on by her coworkers.

The best way to accommodate the collaborator is to ensure that she has access to the best collaborative development tools that you can provide. Getting her to use them isn't a problem. Instead, she spends her time proselytizing the tool's uses to her coworkers. The collaborator wants to work with others. She wants to communicate what she's doing to everyone else, but more importantly, she wants to understand the work that is being done on the rest of the project. She isn't productive if she cannot see what is going on with other aspects of the project. If she doesn't have that information, she seeks it out, possibly disturbing the productivity of others if she doesn't have ready access to the information she wants. By introducing policies that help ensure that information about the project is available at all times, you allow the collaborator to get information whenever it is useful, without interrupting her coworkers unnecessarily and without needing to wait unproductively for information to be delivered.

13.1.3. The Lone Hacker

The lone hacker is a cowboy who codes rapidly, and without regard for a regimented development process. He keeps odd hours, and tends not to communicate with other developers more than necessary. The results of his work are technically exemplary, but can be lacking in documentation and adherence to prescribed style. To him, Subversion is a minor part of the software development process, and exists mostly as a tool for adding changes to the project in large blocks. He is unlikely to make a lot of use of Subversion's advanced features, and mostly uses svn update and svn commit, with the occasional svn status.

The lone hacker can (and does) often make excellent contributions to the project itself, but can wreak havoc on carefully designed development processes. He comes in late, and goes home latereally late. When he sits down at his computer to work, he picks a task from his to-do list (which is often at least partially in his head) and dives right in. As far as he is concerned, tasks are easiest to complete in large chunks, so that's how he does them. Often, he forgets to commit after individual tasks. Frequently, he only makes a single commit at the end of the daywith log messages that are cryptic and only marginally useful to all but himself.

The best way to handle a lone hacker depends a lot on the environment he is working in. If his contribution is valuable, and the development process allows it, you may be best served by giving him the freedom to be creative and productive. By using task branches and/or pre-commit hook scripts that validate commits against policies, you may be able to gently conform his process to a more collaborative effort, without making him feel as if his creative freedom has been stifled. If the overall development process is more strict, the strictness of automated checks can be increased accordingly. Automation of mundane policy tasks can also serve to help constrain a lone hacker. For example, if he has to create his own task branches, he may be inclined to forget and commit directly to the trunk or combine multiple tasks into one branch. On the other hand, if the task branches are automatically created when a task is assigned to a developer, he may be more inclined to use them properly.

13.1.4. The Guru

The guru has been around the block several times, and has all the tricks up her sleeve. She draws on her experience to both develop and help others less experienced. Her workflow often floats between personal implementation of tasks and offering aid to others. As such, she frequently makes use of svn switch, svn cat, and svn diff to view and test other's work, which is usually discussed over e-mail or instant messaging. Additionally, she often has multiple working copies that have different revisions or sections of the repository checked out.

The most valuable resource a guru provides is her knowledge. That knowledge, applied to the project at hand, can be invaluable. However, by imparting that knowledge on others in the project, the value of her knowledge is increased ten-fold. Therefore, it is important that the Subversion repository be set up in such a way as to maximize her ability to transfer knowledge.

• Provide Web-based repository browsing, to make it easy for the guru to check out other developers' source in order to comment or answer questions. The repository browsing features of Apache/WebDAV may be sufficient, but a Web frontend such as WebSVN, which allows for additional features such as examination of previous revisions and graphical diffs between files, is a much better choice.

• Define properties that can be used for providing comment on files in the repository. If a developer seeks the guru's advice on a problem, the guru may not be in a position to provide her help at that particular moment in time (she may also not be in the same geographical location as the developer seeking help). It would, of course, be possible for her to provide her response via an external route, such as e-mail or instant messaging; however, if she can attach the comments to a property associated with the relevant file, it will never be lost, and can be easily retrieved in the proper context.

• Sometimes, it is useful for the guru to make actual modifications to code in the repository in order to properly illustrate an answer to a question from another developer. It isn't usually appropriate for the guru's changes to be immediately committed to the main trunk of the repository though, as she isn't the person responsible for that section of code and may not always have the opportunity to know all of the consequences of her change. In these cases, it can be useful to provide every developer with areas where she can create private branches. Then, the guru can create a branch and make the changes there, leaving it up to the original developer to merge those changes back into the main development trunk as appropriate.

13.1.5. The Rookie

The rookie is just starting out as a developer, and hasn't developed a personal workflow process yet. He is prone to experimentation and tends to make a lot of mistakes from lack of experience. In addition to routinely seeking out advice from the guru, he needs to make frequent use of svn help, as well as any policy documentation specific to the project (a good reason to develop such documentation).

Automation can be a great aid to the rookie programmer. Like the lone hacker, he is prone to forgetting small details and has a tendency to incorrectly follow policy procedures (not because of a cavalier attitude, but due to a lack of experience). In addition to safeguards put in place to automatically check for adherence to policies, custom tools that automate common tasks can be very useful, as can a good GUI-based Subversion client. It may also be a good idea to perform frequent peer review sessions that look at his use of Subversion and other tools in addition to the actual code he is writing. It is much easier to change a log message a week after the commit than it is six months after the commit, when no one remembers why the changes were made.

13.1.6. The Hobbyist Programmer

The hobbyist programmer is not developing as a nine-to-five career, but rather as an evening hobby. That means that she is much more interested in fun than she is in following a complex procedure designed to improve the manageability or efficiency of a project. This doesn't mean that she is an amateur, just that her priorities are likely to be different than those of a professional developer. She is unlikely to be a Subversion guru, nor is she likely to have much desire to become one. In most cases, many (if not most) of the developers involved with any given open source project fit this archetype, which means that most open source projects will needs to accommodate her development efforts. There are several approaches that can work.

• Keep the process simple. Make sure most development is done on a single branch, and don't use complex processes that involve specially formatted log messages or custom properties. Provide clear documentation for what should be in a commit log, as well as any other (simple) policies for committing new revisions. Where possible, use hook scripts to enforce minimum compliance. For example, you might have a hook script that checks to make sure that there is never an empty log message, or that the submitted code passes a style check.

• Make use of trusted "core developers" who receive code changes from contributing developers and then perform the actual Subversion repository commit themselves. In addition to allowing you to take advantage of more complex policies for using Subversion (due to a developer base that is presumably more dedicated to the project and thus willing to learn), this also allows your project to readily accept contributions from a wide range of contributors and test them before applying the contributions to the repository.

• If you want to readily allow a wide variety of developers to commit code directly to the repository, but don't want the hassle of vetting each developer's ability to properly apply changes to the project, a third option is to make use of individual developer branches. Each developer can be given his own branch of the main development trunk, with permission to commit. It then becomes his responsibility to maintain that branch and make changes, which can then be merged into the main trunk after being tested by a smaller core developer group. This has the advantage of allowing more developers the ability to preserve their work in the repository, while maintaining the integrity of the primary project.