Finding bugs in Subversion's mixed revision working copies

Question

The project I work on has recently been switched from a horribly antiquated revision control system to Subversion. I felt like I had a fairly good understanding of Subversion a few years ago, but once I learned about Mercurial, I forgot about Subversion quickly.

My question is targeted at those who work with a sizable number (15+) developers on the same branch in Subversion.

Let's say you checkout rev N of the repository. You make some changes and then commit. Meanwhile, other developers have made changes to other files. You hear about another developers changes to subsystem X and decide you need them immediately. You don't want to update the entire working copy because it would pull in all sorts of stuff and then you would have to do a lengthy compile (C++ project). The risk I see is that the developer updates only subsystem X not realizing that the new code depends on a recent change in subsystem Y. The code compiles, but crashes at runtime.

How do you deal with this?

• Does the developer report what they think might be a bug (even though it's not a bug)?
• Do you require developers to update their entire working copy before reporting a bug? Wouldn't this deter bug reports?
• Do you prevent this situation from occurring through some mechanism I haven't thought of?

Answer 1

Since you committed all your work in progress, you have no reason not to update your copy with the entire latest revision. The lengthy compile is part of the price of a large project. The compile time is almost always less than the time spent trying to determine whether you have a bug, or whether there's some obscure incompatibility because you didn't check everything out.

That project had distributed compiles to all the workstations in the group. Since we had about 15 computers for the task, that meant what would normally be a 6 hour or so build took about 25 minutes.

Answer 2

The responsibility to keep track of dependencies is the develloper who introduce it. In this case develloper X should make sure the change work with current version of other subsystems. Or at least document which versions it works with.

The ways I have seen helping devellopers deal with this are.

1. Include dependency checking in the build system. Many open source project does this in a .configure script.
2. Configure the version control system to handle this for you. I don't know to do this in subversion.

This is obviously not a cure for long compile times but it helps to avoid unnecesary rebuilds. Complex dependeny graphs is also an indication of questionable design. It may be good idea to refactor the code to reduce coupling between subsystems.