Question

I typically work on small-sized projects that involve only 2-3 people working on the same codebase concurrently.

The usual routine for me is as follows:

1. Scour through bug reports, pick a bug by priority, and write the fix
2. Create a diff/patch (let’s call it patch “alpha”) of the changes to the codebase (ie: svn diff > ~/diff_alpha.patch)
3. E-mail the patch to colleagues where they can visually inspect the diff against the codebase and point out errors or suggestions
4. They tell me what changes are required, I put them in, and then re-email my team with the modified patch
5. Once everyone agrees that the patch is good, I apply it to the codebase, merging in other people’s changes if necessary, re-build, re-test, and commit.

The problem here is that I usually have to wait a couple of days for all the approvals for the modified final patch to come in, and during that time I (obviously) want to work on other patches.

If I go work on another bug and it affects the same file I’m working on in the previous patch, it means that when I want to commit the previous patch (alpha), I have to:

1. Backup my current work to a new patch (ie: patch “bravo”), via svn diff > ~/diff_bravo.patch
2. Revert my current working copy (svn revert -R .)
3. Apply the old patch (patch -p0 < ~/diff_alpha.patch)
4. Commit the old patch (svn commit)
5. Apply the patch I was previously working on (patch -p0 < ~/diff_bravo.patch)
6. Continue working on the code related to diff_bravo.patch

This is annoying as I generally have to hand-merged conflicts between diff_alpha and diff_bravo.

The other approach I tried was just continuing my work on diff_alpha without creating a diff_bravo. Then, when I have approval for all the code in the original diff_alpha I e-mailed out, I do the following:

1. Backup my current work to a new patch (ie: patch “temp”), via svn diff > ~/diff_temp.patch
2. Revert my current working copy (svn revert -R .)
3. Apply the old patch (patch -p0 < ~/diff_alpha.patch)
4. Commit the old patch (svn commit)
5. Apply the patch I was previously working on (patch -p0 < ~/diff_temp.patch)
6. Now I can continue what I was doing without having to hand-merge, but I will receive tons of fails hunks in my “patch” command as half the code in diff_temp was already committed in diff_alpha. I do not find this acceptable.

Any recommendations for handling multiple tasks/bugs on a common file so I can minimize SVN conflicts?

Answer 1

This is what branches are for. You create a branch for each bug and work in that branch until you are ready to consult with your team mates. The branch can be checked out by the team members and inspected (update when you did new changes). When everyone agrees, merge branch back to trunk.

The team members can check the log of each change you made to the branch (essentially your patch in your question) or open the changed file and see the applied changes in context (they can even access previous version(s) of the files to see how it was before the change).

You still have to alert your team members to check the changes, but do not have to explicitly send them the change youself — they will get it from the cental repository.

You can have multiple branches (one for each bug) and can work on them simultaneously. When merging to the trunk, SVN should do the merge automatically (occasionally pointing out conflicts, which you can resolve manually.

The conflicts might arise from the fact that the branch was created from an older version of the trunk and the current trunk state (containing some changes from other branches) is conflicting with the changes in your current branch. You manually resolve them as it makes sense. Re-test to make sure all is still well.

UPDATE: Based on Lazy Badger’s comment, your team members can put commit monitors in place to alert them when you make a change to a (particular) branch.