Home/ Questions/Q 747697
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T14:14:07+00:00

In the project that I’m working on, we are using SVN with ‘Stable Trunk’

  • 0

In the project that I’m working on, we are using SVN with ‘Stable Trunk’ strategy. What that means is that for each bug that is found, QA opens a bug ticket and assigns it to a developer. Then, a developer fixes that bug and checks it in a branch (off trunk, let’s call this the bug branch) and that branch will only contain fixes for that particular bug ticket

When we decided to do a release, for each bug fixes that we want to release to the customer, a developer will merge all the fixes from several bug branch to trunk and proceed with the normal QA cycle.

The problem is that we use trunk as the codebase for our CI job (Hudson, specifically), and therefore, for all commits to the bug branch, it will miss the daily build until it gets merged to trunk when we decided to release the new version of the software. Obviously, that defeats the purpose of having CI.

What is the proper way to fix this issue?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As you note, one purpose of using a branch is to segregate specific code fluctuations from ticket-fixing and feature development away from the trunk. But once the feature or ticket is complete, you should merge it back. In Subversion, branches are better used to track sets of related features (like those for a release), not individual features. Otherwise you will quickly wind up with unmanageable numbers of branches.

    Furthermore, why delay the integration at all? The longer you wait between releases, the higher the likelihood that your isolated change will conflict with another change made since then and/or produce further instability in your system once merged back.

    My preferred strategy is to do something like this:

        [begin work on 0.4 branch]
       |
       |
       v              
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable".
         \       |          |        Contains all commits.
    ver   \   [merge from trunk]     Developers commit to trunk.
<-- 0.3    \     v          v
            +---(a)--------(c)-- <-- Branch is "stable".
                                     Contains selected commits from trunk.
                                     Know beforehand what's going onto branch.

    Now, once you’re ready for release:

    [trunk]
(*)---(*)---(*)----------------------------[development continues]--->


[0.4 branch]                        No further development on branch unless
(*)---(*)---(*)---[0.4-release]     spot fixes are needed. Then re-tag (0.4.1)
                          ^         and re-release.
                          |         
                          |
                       [make tag on branch; release from stable branch,
                        not unstable trunk]

    I know you asked about the best way to coerce your continuous integration system to do this. But I would respectfully suggest that given that Hudson is recognized as a relatively capable CI system, the fact that you’re having a lot of trouble shoehorning your development model into it is a possible sign that it’s not a process that lends itself well to CI in the first place.

    Our typical practice is to have two base builds per project: one against trunk and one against the current release branch. This way you know that:

    • Whatever is being updated is being integrated correctly (trunk)
    • Whatever your release target is, if you stopped working now you would still have a correct and working (just not fully featured) build.
    • 0