How do you keep track of code changes in a shared codebase?

Question

I'm interested in hearing what other people do to understand/review code changes that were committed by other team members to a version control system.

What processes do you have to make sure that everyone who needs to know about a revision is notified?

How well does this system work for you (and your team)?

FYI, we currently use our own homegrown ant build script that checks out code from CVS and pushes it to all of our testing machines every 15 minutes. We write web-based code that is all interpreted. "Builds" of the system rarely fail and our testing code takes a few hours at least to run so we can't run it after every commit.

Answer 1

CruiseControl.NET provides the ability to broadcast emails to developers when a change is checked into the source control repository.

Although my preference is a "pull" rather than "push" solution, whereby developers can view changesets/checkins through the website.

Answer 2

Generally in our system we don't track changes done by others, only on conflict of files or interest we check the commits done by others.

For Code review we have separate system (CodeStriker) which raises automatic code review request on commit.

We use SVN, where you can use post-commit hook to raise any such notification.

You can also use SVN Notifier.

We do have CCNet configured which raises passed/failed notification on commit.

Answer 3

Current system

My company currently relies most heavily on person-to-person communication. It is the responsibility of the person committing code to make sure it is reviewed before the code is checked in.

After being burned once, we added an extra code review process via a CVS commit hook for the most important ("core") files we have. When someone changes a file that is marked with a comment containing @core, an email is sent to the team responsible for that file and the committer needs to have the code reviewed with another member. This email is sent every 2 hours until it is marked as complete in our bug tracking software.

People generally update their source code daily first thing in the morning and hope that none of the recent changes disrupt them too badly.

Broad changes to the code-base need to be announced to everyone over an email list.

---

Where the process breaks down

1. When people introduce bugs into the system it becomes difficult to know what files have been changed recently. (We use nearly all interpreted code so blocking the build isn't caught by a compiler)
2. Without easy access to a stream of commit messages/files changed it is hard to know exactly what files people are touching. (Does anyone have a good tool for this in CVS that they actually use day-to-day?)

Answer 4

I don't know what platform you're working with, but the easiest thing is to get CruiseControl, Hudson or something similar and simply give the address to whoever has interest (read: intrest) in the code. When you're using a build system like that, check-ins become public, builds become public, thus, successes and failures are public. Whatever the case that you're looking for; you get to do a few things:

• Follow the changes as they happen.
• Allow interested parties to participate
• Allow interested parties to be responsible for communication of individual code changes
• Give an RSS link to the builds
• Provide email when a build happens

This is really useful for my team, as well as the teams that we interact with, because it allows everyone to get on the same page, without wasting time communicating minute details to an interested party that may or may not understand (read: care) about the update that you just committed.

Answer 5

We use FishEye on our CVS / SVN repositories. It is a commercial tool, however it worths every penny for us because it adds very good search and track features on our code base:

• It groups CVS commits (if you commit a couple of files at once with the same commit comment it will be one changeset in FishEye). These changesets form the starting point of code reviews.
• It can be configured to enable watches. After it every developer can set watches on interested folders or files and have immediate (or daily) e-mails about changes in them.

Also, we use Hudson as a continuous integration system. After we installed the Chuch Norris plugin, everybody try hard not to break the builds :)