A Subversion horror story

Every once in a while the stars align for one, and only one single purpose; to drive developers in the twilight zone of bug madness. Unlike many other occurrences, this time the problem wasn’t code related, it all happened at the version control level.

It all started a couple of weeks ago, when a feature I have developed on my branch had to be deployed on our test servers. Nothing fancy, a simple switch from trunk to my branch. And surely, at the rapid pace we develop software (weekly releases) my colleagues as well had to deploy their modifications on the test server.

Piece of cake I said, made another branch from the trunk and integrated my branch in it, conducted a svn branching/merging 101 workshop to my team mates (which have never used/heard of branches/tags before), and wrote a document on the steps required for merging new code from trunk to the branch deployed on our test environment. Gave the most basic rule to follow:

Always before switching make sure no local modifications exist. Diff and revert if necessary, but don’t switch around until your local copy is clean.

Two weeks in everything seemed fine. Then BOOM, the seed was planted; because one day one of the developers, and I’m not going to point fingers, made a commit without the files generated by our ORM. Someone else noticed it after deploying the code on production and running the ORM code generator. Being asked about it I said the solution is simple:

Just add the files to subversion and you’re done with it.

Without other questions they poured a bit of water on the seed, by adding the files not on trunk, but on the branch from our test environment. Day was over, it was time to go home. Next day, back in the office and I’m asked why subversion has flagged more files that the ones that where changed on trunk since the last merge.

It’s just svn, version 1.5.x really likes to go nuts with mergeinfo properties.

And the seed flourished.
Minutes later stuff, that shouldn’t have, got broken on our test server… what? One look into subversions log and almost all files have gotten property changes upon the last merge.

The reason? The subversion switch from trunk to branch got broken somewhere, leaving around a large number of files still pointing to trunk. And as with the mechanical way they followed my written down merging operations issued a commit, task finished.

But what’s the seed got to do with this? The only reason the switch failed was because the mentioned ORM generated files where unversioned on trunk, but had incoming adds upon the switch.

Three hours in, I brought back the code to stable version on both branch and trunk (committing was done to both due to the partial switch).

But no, the story doesn’t end here. Even after stabilizing both source trees, another problem popped up, I could no longer synchronize the branch with trunk. The all so mystical mergeinfo property conflict appeared.

The now tired developer used: svn merge trunk --accept theirs-full
It was super effective.

p.s. Might have not sounded too horrific for you, but I remember the face my project manager made when I tried to explain him the issues.

Filed under Insight

blog comments powered by Disqus