I have to define the new way of working for a development team which goes from a one man unit, to a distributed team with programmers al over the world. The team will work with svn. This is a non-negotiable thing. I recommended that they switch from svn to git, but that is not going to happen. This is the first time I do something like this. At the moment I think about something like:
- Every developer has his own branch and does his development on this branch. (This is my preferred way and in my research I saw this also recommended. But I also saw often that svn users did not like to do this. Especially on the long term I think this would bear more fruit. Or am I overestimating the difference?)
- At least every morning before a developer starts working he merges trunk into his branch.
- Normal work should be checked in the same days as it is started. For work that takes longer a special branch should be created. This branch should also have trunk merged into it at least at the start of the workday.
- Every-time the developer has added something that can be tested, he should run the unit tests. Before running the unit tests an automatic merge is done. If this results in conflicts those have to be solved.
- When the developer thinks he has something that can be committed he calls the unit tests with a commit flag. When everything is OK the commit and follow-up actions are executed.
- A pre-hook is defined that checks that the merge and unit tests where successful.
- After the commit is done successfully a post-hook will create an integration server where the above tests are run again and integration tests are performed. When it is not a special branch: on success an acceptation server is created with this branch and the branch is merged (--reintegrate) into trunk. The developer is always notified of the result.
- A developer is only allowed to go home when his version is successfully committed. Ideally it should also pass the integration tests. (This sounds a bit harsh, but I added this because I have seen developers not committing for weeks because they had not changed much yet. With all the merge problems this created.)
Because it is important to minimise things that can go wrong (people that would give help when there is a problem probably sleep at the moment it is needed, so it should be minimised at 'all costs'), I am thinking about locking svn trunk before the commit and releasing after the automatic steps are done. In this way it should be nearly impossible that the 'Merge Back Into Trunk' goes wrong. The idea is that the tests are reasonable fast and it is better to wait a little before the commits are done, then that there is a chance that the automatic part goes wrong.
Is this an acceptable way of working?
If so: can this be done with svn?