Subversion branches and release plan [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

Currently we are following a simple release plan for our projects as follows;

1. Developers committed changes to subversion repository.
2. Build changes to QA server.
3. Build changes to production server.

The issue is we use one single source code set in SVN trunk for all these steps.

Therefore we cannot control QA server release (ex: avoid some requirements).

We have very complicate release occurrence as some days we have to release 5-6 times to the QA server.

I guess using a subversion branches I can overcome this issue. Hopefully I can create a separate branch for QA/live server release and I can merge necessary changes from head/trunk.

Or is this other way around? Keep head/ trunk version for QA/ live server release and create a branch for development commits.

What is the correct way?

Please let me know whether there is any better way/tool for handle this situation.

Thanks.

Answer 1

There is a quite popular approach to branches in SVN. It's described here: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

In my project (one-person project with a separate release cycle) I use both release and feature branches and have no problems.

Exact branch policies may vary, here is what works for me:

• Trunk (only one): all automatic tests pass, contains only completed features and bug fixes
• Feature branch (usually multiple): dedicated to a single feature or a bug fix, usually builds, automatic tests usually pass, after completion is reintegrated to the trunk and deleted
• Stabilization branch (may be multiple, but usually one): dedicated to a planned release, automatic tests pass, used to generate builds to be sent to QA, internal/external release tags are created from it, some fixes or even features may be merged here from the trunk

Answer 2

What is the correct way?

It's an opinion, but create 3 trunks. One for development, one for QA, and one for production.

A development branch should only be necessary if you're forking the project.

The QA trunk could branch for unit tests, while maintaining the trunk for integration testing.

The production trunk would never branch, but would be tagged for each production release. If anyone has to fix a problem, the code would be exported rather than checked out. The changes would be applied to the development trunk.

• Check out development code
• Apply production fix changes
• Commit development code.

You'll need a person and a process to move code from the development trunk to the QA trunk, as well as a person and a process to move code from the QA trunk to the production trunk.