5

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:

enter image description here 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.

  • 1
    It is good that you ask here, since your approach seems weird. However, I am sure you will get downvotes from people here who don't understand the downvote button is not for bad ideas, only for bad questions. Besides that, someone will writea good answer along the lines of "use Git & Pull Requests". – Doc Brown Jan 7 at 6:31
  • Please clarify when do you mean by "merge" and "commit". What do you merge and where to in each case – max630 Jan 7 at 6:33
  • @DocBrown It is a ba idea. Why? – Cecil Westerhof Jan 7 at 6:33
  • @max630 Is the description clear now? If not what should I add? – Cecil Westerhof Jan 7 at 6:44
  • @DocBrown I would like to use Git, but I am overruled on that. So for the moment I need to work with svn. I will add that to the question. – Cecil Westerhof Jan 7 at 6:57
4

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).

  • "Trunk-based" development is even worse in long-term perspective, than branch-based OP's. If you don't know it you have to be silent, baby! – Lazy Badger Jan 7 at 10:23
  • Thanks for the answer. I got something to think about. ;-) The reasons for the different branches is that I want to be sure that the version on trunk is always a correct version. Especially because all the new programmers will be new to the system. So I am afraid that breaking the integration tests would not be rare. – Cecil Westerhof Jan 7 at 10:34
  • 1
    @LazyBadger: Then why is there a growing trend to stop using feature branches and only use the develop branch? – Bart van Ingen Schenau Jan 7 at 10:50
  • 2
    @CecilWesterhof: The "no new commits" can not be enforced by tooling, because tooling can't tell if a commit introduces new functionality or if it fixes a bug introduced by the previous commit. If you think a trunk-based strategy isn't right for your team, then I would recommend a feature-branch based strategy (so a new branch for each feature/ticket) – Bart van Ingen Schenau Jan 7 at 10:54
  • 1
    @JimmyJames: I am not aware of a universal solution. Both trunk-based development and feature branching have advantages and disadvantages. – Bart van Ingen Schenau Jan 7 at 19:29
-4
  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"

  • While it 'may' be the case that some or all of those outcomes could potentially happen under the OP's branching strategy, this doesn't doesn't actually answer the underlying question because there's no objective explanation of how or why any of those problems could actually come to pass as a consequence. There's nothing here which could provide any possible hint toward any kind of solution or alternative. – Ben Cottrell Jan 7 at 12:23
  • @BenCottrell - I beg your pardon, but "Dude, it will be Road to Hell" is the answer for Q: "Is this an acceptable way of working?", because contain predicate NO – Lazy Badger Jan 7 at 17:47
  • Indeed, but a "don't do that" answer doesn't help in pointing the asker in the right direction - see this topic on the help centre How do I write a good answer? – Ben Cottrell Jan 7 at 19:09
  • @BenCottrell - I don't want do the job of OP for nothing. I want to do that I done - give ideas (for free). I am not a nanny for babies – Lazy Badger Jan 7 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.