Is it a good idea to lock svn

Question

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:

White text are things that are done manually. Blue text are things that are done automatically.

• 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?

More about the way of working I am thinking about.

Answer 1

In the way of working you describe, there is very little advantage to using branches. With all the merging back and forth, you might as well be working directly on Trunk, except in the (hopefully rare) case that your commit breaks the integration tests. Note that every developer always has a private, local working environment that can be regarded as a kind of branch as well.

Although working with a single (trunk/develop) branch is common in SVN, you can also use the branch-based strategies that are more common among GIT users. Only strategies that depend on (or assume) a distributed VCS are not usable with SVN.

My recommendation would be to let go of the separate branch for each developer and let them work on Trunk for small changes. SVN will enforce that all required merges are performed before they can commit. For larger features, a separate branch can still be useful to isolate the other team members from the ongoing unfinished work.

Each commit (to Trunk) should still trigger a run of the CI tests and there should be an agreement that no new commits will be made as long as the CI system reports problems (with the exception for commits to resolve the problem).

Answer 2

This seems to me a very good question. We also had same issue.

You may want to check Trunk-Based Development:.

One line summary:

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

Answer 3

1. It will stop work rather fast in real development
2. Developers will get "Merge Hell" even before p.1 (read about "Cyclic merges" /and you'll have it, sure/ in SVN samples and some other "glithes", not real troubles)
3. Locking will be (mostly useless) long-time process for real code-base (read carefully svn help lock) and add nothing valuable into well-organised process (well separated code)

Your (personally yours, nor team nor suggested procedure) biggest problem from my POV is your state - I suppose, you aren't programmer or at least coder, but "manager", thus can't see map of rack in your "workflow" (SVN-related and not related). We, in Russia, have good saying for such cases (poorly translated by me, sorry): "It was smooth on paper, but they forgot about the ravines: how to walk on them"