svn best practices for dealing with coworker

Question

Hi all,

I'm on a small team of about 6 people. Most of the group is careful to make sure their commits don't break trunk and use short-lived feature branches when they need to work on something for more than a couple of days, so they can check in code without destabilizing things for everyone else.

And then there's the other guy. He is prolific but not thorough, and he's also frequently in the middle of juggling several tasks at once. For better or worse, those three things relate to each other. For a long time, in order to make everyone happy, we tried to have a long-lived "experimental" branch where he lived, and the rest of the developers lived in trunk. The idea was that we'd merge features as complete back from experimental, and do periodic updates from trunk->exp.

The result was as you might imagine: infrequent updates each way lead to divergence and several of the merging anti-patterns listed here.

I've read a lot of general svn branching guidelines, including the above link and Eric Sink's stuff which are frequently cited here. I'm not sure what to do. I fear we're going to to back to having him commit straight to trunk all the time, which will lead him to using in-code methods to keep from destabilizing other's work, which in turn will mean that we can't even use svn to help make the merging easier.

So ... advice?

Answer 1

From: http://svn.apache.org/repos/asf/subversion/branches/performance/doc/user/svn-best-practices.html

I would recommend you use The Branch-When-Needed system:

(This is the system used by the Subversion project.)

• Users commit their day-to-day work on /trunk.
• Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
• Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
• Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit. However, if you use continuous integration, the CI server will do this for them and notify everyone it is broken/fixed.

Answer 2

You need social advice, not technical advice. SO might not be a good place to get that.

That guy will have to learn how to properly behave in a team, or he will be a nuisance, no matter what you - technically - do about him. Since his problem is a social attitude thing, not a technical problem, it's very likely he'll be a problem in other ways, too.

People like that can very seriously break a team. If you cannot get him to learn to behave properly, he probably will.

Answer 3

Quite a lot of effort for a single rogue coder, but you might just write a pre-commit hook which checks for 'bad practices' (either by tokenizing code & checking yourself, or by a an already built syntax checker for your language), and possibly filter on username (so a 'trusted' coder will be able to break some rules), so you can deny a commit if the code is not adequate.

Best solution: getting your coworker to play nice, but that might be even more work.

Answer 4

I'm going to suggest that this is a technical problem: your architect doesn't know how to introduce change to a live system (even if it's only live to the developers).

For example, he's (apparently) not starting with a stub, then adding functionality gradually, altering bits of other code in non-breaking ways.

He's probably focusing on the "real work" of his functions, changing all the other code in whatever ways it takes to make his work. I realize that from his point of view, thinking about the "hard parts" seems to be the best approach.

Someone has to bell the cat and ask him to stub things out first. It's not that hard.

Answer 5

In my opinion, a separate branch is not the solution as you already discovered. There can be several causes for this person breaking the build:

1. He is commiting incomplete features: solution is to explain him that he shouldn't do that. The previous answer about 'stubbing' is good.

2. He is working in different things at once. It is not advisable to do so, at least in the same working copy. If he really has the need to work in different features at the same time, I would suggest that he uses different working copies in the same machine, one for each feature. This can help him clarify his mind about what is he doing at each period of time, and also he would suffer in his own flesh when one commit in one wc breaks the build for the other wc's.

Answer 6

He might look into using git-svn to juggle the multiple tasks he's working on and commit features to trunk only when they are ready. But that's really not that different than using svn to create multiple temporary branches.