Subversion - Async development cycle... two trunks?

Question

Currently in our enterprise we have a situation that i think it's not very common, or at least i haven't found a similar case in Internet. My problem is that we have software that can evolve by more than one requirement, and both not necessarily will coincide in their release date.

We have a development cycle where all software is developed in a "DEV" environment, and then it's handled to SQA so it can be tested on "LAB" environment; if all works OK then this software is moved to "PROD" environment. The problem i am facing here is that i cant use a single trunk and i don't see how a single branch could work either.

For example, lets say i have requirements A and B, one to be released today and the other a week from today. Both have reached LAB environment but today's release to PROD environment only has to contain A, since B is not yet needed by our business users (and it cannot be released early because it would introduce some error's to others systems). Both requirements where developed in different branches (they respond to different needs). In this case my problem is that i can't have a single trunk where developers can merge to see both changes in "DEV" environment, and then use the same trunk to feed "LAB" environment since it would have source code not yet scheduled for release.

I think i should also mention that having a separate development environment for each branch is not possible because this software is based on PL/SQL (Oracle) and our current test database is about 350Mb in size, so having a different one for each requirement would be quite expensive and hard to manage.

Any suggestion or similar experience would be appreciated.

Regards

Answer 1

It sounds to me like you could benefit from using a distributed VCS (git, mercurial, bazaar, etc.)

Answer 2

Based on your last paragraph you've got quite a pickle. I believe the best practice for this is to branch per feature and merge the features into the trunk as they're needed/released. I don't really know if there's a second best practice for improving your situation (But I'm not that smart)...

Answer 3

I would suggest following:

• product-1/
  • trunk/
  • branches/
    • feature-branches/
      • req-A/
      • req-B/
    • pre-lab/
    • lab/
    • prod/

Developers start developing for new requirements on the respective feature-branch. Then you reintegrate the feature-branches which have been decided to be included for environment LAB/ to pre-lab/, where you can integrate the changes for new features and bugfixes from trunk/.

As soon as you know that works (will take some time, as any integration step merging from several sources), you merge all changes from pre-lab/ to lab/. When you restrict yourself to merge only from pre-lab/ to lab/, this merge will always be clean, i.e. one mouse-click away.

In trunk/ you could merge all feature-branches and bug-fixes together, but depending on your project-structure and software-development-process this may need some further discussion.

Be sure to use Subversion 1.5, as this merging will get you lost in hell with older versions.

Answer 4

In most cases what you need is to test the resultant application with features enabled AND disabled so that you can choose what to enable or disable at release time.

The point is that if you create a testing release that contains both and then go and completely remove one part, regardless of your versionning system, you could end up creating an integration problem, which you wont know about and you'll have already pushed it to the production server.

Regardless of what you do, you still need to test the exact product you will give to the client.

A release should then be what is going to be tested, not what is going to production. What will be going to production is the tested release. At that point it simply a question of creating a branch for each release or feature and merge what is needed.

A merge operation doesn't need to be for everything. If the commits are well done, you should be able to merge just the features (comits and/or files) you need between branches easily. Also to note that SVN only has the ability to keep the history of merged branches since 1.5/