Question

I am currently working on a two man project where we use Subversion as our Source Control. Right now we both create branches and do our development in those branches and then merge those changes into a copy of the trunk before committing the trunk.

The problem we are having is the huge overhead of keeping everything updated.

Example of our work flow

1. I run Update on my trunk copy to get latest updates
2. I merge trunk updates into my branch
3. I work on my branch
4. I merge my changes into the trunk
5. I update trunk to see if there are any new updates
6. I commit

Problems

1. It is hard to keep track of which revision were merged even when writing i explicitly in the log
2. Sometimes I have a completely uptodate branch, but I can’t merge the updates back into the trunk for committing.

Could someone recommend a simpler workflow? Sometimes we work in areas that affect the other persons code and at the moment it is unavoidable, so we need to keep things updated. I like to commit to the trunk at least once per day so things don’t get too far out of sync.

Thanks

Answer 1

For the last ten years or so, I have worked day to day directly on the same branch or trunk shared with 5-10 people working on the same module or project. You update before you commit, and fix the problems immediately. You are already pretty close to that scenario, given that you merge everything on a daily basis. It helps to have a continuous integration build machine run unit tests. If your colleague has made a mess, you can update to an earlier revision and works on that until he/she is done cleaning up.

You only need a branch if you want to re-engineer something in a way that it won’t work for the rest of the team for a week or more, which is often avoidable.