Subversion with Continuous Integration

Question

Sorry if answers to this question already exist, I did not find them yet.

I'm member of a web development team, we maintain a web portal. Release Management works with Subversion. This is how I work when adding new features to the portal:

• Create a new Branch by copying the Trunk
• Develop in that Branch
• Periodically merge updates from the Trunk into that Branch (I want to know if Framework-Changes break my code, before it goes to UAT / Integration, e.g.)
• Re-Integrate the Branch into the Trunk in order to let it go live

Now we have a problem with Continuous Integration:

• Periodical Go-Live every X weeks
• Several Branches exist which are planned to go-live on different dates
• Every X hours a day, Integration Server does a Trunk checkout and merges all Branches (which should explicitly go to Integration System) into it
• The Trunk updates which have been merged into each Branch (see above) now generate Tree Conflicts

What is the Best Practice for that? Re-Integrating doesn't work for merging multiple Branches, because as soon as one Branch is integrates, the working copy isn't clean anymore. However, Continuous Integration must be possible somehow...

If Trank changes are merged into each Branch, different revisions are created. But the files should have the same content and be equal. Isn't there a merge-option saying "ignore a conflict if the two new/changed files are identical"?

Thanks for any help.

Answer 1

What you described is not continuous integration because of the following requirement:

Every X hours a day, Integration Server does a Trunk checkout and merges all Branches (which should explicitly go to Integration System) into it

Real Continuous integration includes following steps:

• Updating source code from one specific branch (trunk, for example).
• Building source code producing build artifact which could be either executed or deployed. Sometimes this phase includes also running unit-tests and inspections.
• Shows build status, whether it was successful or not: green or red.

If you have several branches, it means that you need to configure several build plans for several branches in order to perform continuous integration for each branch separately.

Therefore, there could be no best practice for what you described because merges should always be performed manually. This is due to the merging conflicts. They happen quite often and can be resolved only manually. Continuous integration won't help.

If you just confused with terms and want to perform what you described anyway, I would say that your development process is little bit flawed. Probably, you do not need to perform merging from several branches simultaneously. All development you deliver most often should be concentrated in one branch. Most often such 'one' branch would be trunk.

In your case it seems that valuable development is dispersed between several branches. That's not right. Once you decide that some functionality should be included into upcoming release, it should be integrated into one (probably parent) branch and stay there as a part of the codebase. Try to reduce number of branches you have.

To sum up,

1. Exclude merge all branches step from your process (this is not to be done automatically).
2. Do merging manually instead.
3. In case you sure you need to have branches all the time, configure continuous integration for such each branch separately.
4. Otherwise (you do not need to keep branches all the time, and they can be easily reintegrated into parent branch once the development is finished) reduce number of branches to a minimum.

Good luck!