Thu, 25/06/2009 - 23:39 — horuskol

When I set up a branched development on SVN the other week, I knew that it would cause some problems down the line. It was my own fault really, and I deserved to get bitten for it just like I did today. Actually, the problem extends to a bit before that, and comes down to a simple case of lack of planning.

One of my ongoing projects has two developers working on different areas of it – but for the most part we’ve been able to schedule development and delivery such that we’ve been able to work out of a single development tree in the SVN repository.

However, a couple of weeks ago, it became apparent that the aspects I was working would need to be delivered independantly of what my colleague was working on. So we set up a branched development. This is pretty trivial when using the TortoiseSVN client. I also took the opportunity to tag a ’stable release’ from the repository as a separate entity, to facilitate future releases.

After branching the development, I had to remove some of the changes already made for the development which could not be released with the earlier set of changes.

Once that was done, we were able to develop the two new sets of changes independantly – always knowing that there would be some clashes in the code we write and some working on resolving conflicts will be needed when we come to merge.

It All Goes Wrong

Merging an independantly developed branch is supposed to be fairly trivial – especially when using TortoiseSVN. You simply have a working copy that you want to get the branched changes updated to, and then tell Tortoise to ‘merge’ from the branch.

What results is a merged development, usually with a small number of conflicts where files have been added/deleted, and some overlaps have occured in changes in the file.

As we completed working through resolving the conflicts, my colleague and I noticed that the merge hadn’t brought some files over. This resulted in a rather frustrating sequence of events where we tried to figure out why. We even dragged in a couple of others to look into it and try and find out what happened. Correction: very frustrating.

The Discovery and Lesson Learnt

What it finally came down to was the fact that the branch had taken place, and then the authoritative version (to which we were merging the branch back into) was reverted to remove the changes that were branched.

As one of my colleagues put it – the authoritative version did not know about some files because they were removed in the reversion and this meant that, because the revisions we were adding from the branch didn’t have an ‘add’ for these files, they stayed removed.

Once this had been realised, we then tried a couple of methods to ‘trick’ the files back – unsuccessfully.

I finally hit upon the solution – revert the revision where the files were deleted in the main tree, and then perform the merge.

Problem solved.

A Deeper Answer

The real problem was that we hadn’t really though about the future of development on this project – and it was only after development for one set of changes started to take place that we realised that there was a more immediate development which would have to be released earlier.

What we should have done was branch any major project developments immediately before starting to make changes, and then merge when they are nearing completion or, even better, once they are ready for release.

Learnt my lesson – hope you learn it, too.