SVN improvement suggestions for my work environment

Question

Hello guys,

Yet another SVN guideline question, I know.

I recently joined a new company which maintains a few websites. We have a few developers and a graphics designer and all of us use SVN. Each of us has individual working copies and sandboxes to work with, and commits everything to the trunk.

Here are the problem we are facing:

1. Sometimes, multiple ppl work on the same feature/bug (eg. me and the graphics guy). In order for us sync our work(eg for me to see the new picture/css), the graphics guy needs to commit his changes and I have to update my working copy. Therefore at the end of the day we have a lot of revisions to merge from trunk to the RC branch.

2. Often we were asked to implement a feature, ok, finished, commit the code to trunk. Then we were asked to fix a bug(to fix this bug it somehow uses some of the code written for the feature, and no body remembered it) Ok, bug fixed, tested, commit bug fix to trunk. The screw up part is later we got told that we would not release the feature but needed to release the bug fix.

There are a few more scenarios but I can't remember now. What changes do you guys reckon that will improve our processes?

Regards

James

Answer 1

That is probably a good time to change svn to some distributed svc(like mercurial or git). I haven't used them, but according to what I've read about it they have less friction when it comes to merging and branching and this seems to be the problem here.

Answer 2

Our shop goes like this ...
The trunk is only what is in production.
If a developer needs to create a change he creates a branch from the trunk. performs his changes in the branch, etc ...
Right before the branch is to get deployed, a merge is done from the trunk into the branch. That way you have trunk + newest changes in branch.
Once the branch has been deployed to production and some testing has been done then the branch that just got put into production is reintegrated into the truck.
Nobody touches the trunk, it is always a working snapshot of production, except for a small window after a deployment.

Answer 3

You can have feature branches that yourself and the graphics guy work toegther on. Make sure you have the tasks written out that both of you will do and when as there undoubtably be some dependencies between both of you (as you seem to be experiencing).

One good way our team used a designer was that we sat down and quickly drew up an 'API' or basic code contract that he can design against at the same time the devs would code against.

Try to integrate often both to your branch and trunk. If there are large gaps in check ins then merging becomes more difficult (code drift). The merge tools can only get you so far.

Bugs do happen after a feature is done, no one is perfect but make sure you have a proper bug tracking system and assign the bugs to the best person for the job (ususally the one who knows most about the feature).

If you have one person knowing the feature and he goes on holiday you can get the situation where no one else in the team would know how it worked. In this situation I have found that it is best to share the knowledge around the team as much as possible. If you use Agile peer(pair) programming can work, perhaps code reviews.

Remember communication is key for larger projects and simply takling to the next person about the tasks at hand goes a long way to share knowledge and understanding.

HTH