CODEWITHSUNDEEP
svnversion-control
MaoTseTongue
MaoTseTongue

Reputation: 1505

How to test new features without corrupting the trunk?

I create branches for each new features. Then I'm merges them into the trunk after I'll sending them on a test site.This means that the trunk is not stable.

I wonder if there is a better approach.

EDIT After reading the comment, I realize that I should have specified that it was a web applcation.So a website for testing each branch seems a bit difficult to maintain.

Upvotes: 3

Views: 295

Answers (7)

Mnementh
Mnementh

Reputation: 51311

One thing is, you could test on the branch, before merging back. Also often the trunk isn't seen as the stable development, you make snapshots from time to time, fix bugs on them without adding features (or even remove features if they are buggy or incomplete) and release these branches as stable.

EDIT: To explain it a little further: Keeping feature branches for a long time separated from the main trunk can cause headaches for integration. Your team recognizes late conflicting changes - not only on source-level, but also on semantic or data-level. Keeping the trunk current uncovers such problems fast. Therefore I prefer to stabilize on a separate branch.

Upvotes: 3

Parthan
Parthan

Reputation: 487

You need to primarily make use of "tags" which is nothing but tagging a specific version of trunk to be something stable. tags are generally used to mark releases, which means that the code is stable for the tagged versions.

The way to do it is maintain a trunk to which all members contribute code. If a member wants to develop and test a new feature, he creates a branch, develops his stuff, tests it, then merges into the trunk. When you decide to release the next stable version of the trunk, then you test the trunk code and if found stable then tag that specific version of the trunk as a release version or stable version. Else, fix the bugs in the trunk or in the branch and merge it back to trunk, test the trunk again and if found stable, tag it as stable release. Here, you always consider the tag to be a stable version, the trunk to be development version and your branches to be experimental versions.

But even here, you need to have some quality control on what enters the trunk and what decides a stable version.

Upvotes: 1

Robin Day
Robin Day

Reputation: 102478

I use the following:

branches: don't always compile, not always stable

trunk: always compiles, not always stable

tags: always compiles, always stable

final testing takes place against a tag before it is then converted into a live release tag.

this way it doesn't matter if the trunk is unstable

Upvotes: 4

Hiperion
Hiperion

Reputation: 451

You can have branches/newfeatures and branches/stable

The trunk isnt stable, but when you "freeze" the trunk in a branch... then that is the stable branch.

Upvotes: 1

Brian R. Bondy
Brian R. Bondy

Reputation: 347216

I prefer to keep the trunk always stable, I have a good discussion on the topic here

Upvotes: 3

Mark Pim
Mark Pim

Reputation: 10064

Can you not get the branch tested before mergine back to the trunk?

Otherwise a Distributed Version Control System like Mercurial might be the way forward. With that you can define new repositories for each feature, and for testing, and push to the 'trunk' repository.

Upvotes: 0

lutz
lutz

Reputation:

Why do you merge a development to the trunk before testing is finished? You could wait until testing made sure that the changes don't break your system before you merge them to the trunk,

What is your general merging strategy? Do you have release branches or do you release from the trunk?

Upvotes: 0

Related Questions