-1

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.

Unknown
  • 863
  • 2
  • 14
  • 29

2 Answers2

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
maxim1000
  • 6,297
  • 1
  • 23
  • 19
-1

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.

Gilbert Le Blanc
  • 50,182
  • 6
  • 67
  • 111
  • There is only one trunk, by convention. the rest are just branches. It's confusing to talk about the development trunk and the qa trunk. – thekbb Feb 12 '13 at 19:51
  • @thekbb: You can set up as many Subversion directories as you want. Each directory has at least one trunk. I have a Subversion directory with 20 trunks, for 20 different projects/ – Gilbert Le Blanc Feb 12 '13 at 19:56
  • Sure. you can make directories called whatever you want. there are no rules... but there are conventions. The standard branches, tags, trunk described in the red book is easily ingested by any tool your working with. That and others will know what you're talking about. – thekbb Feb 12 '13 at 21:57