What is a good SVN best practice for feature/bug releases?

Question

I've been reading several questions here on StackOverflow but am not really satisfied. The situation that I am in is the following:

Large web app project (complex parts, a few unknowns):

trunk is the main stable release

branches has bug releases e.g. bug-503, bug-524, some of these bugs are complex touching several files, others not so much, some get fixed and then revisited several times.

tags I am primarily using tags for the different releases, we have three environments: production, sandbox and dev ... the tag release helps keep a revision number consistent across the envs so that at any given time we can compare what release number the environment is using

So right not i do much of my work in branches, and merge back into trunk and produce a tag release. the dev environment usually has a build that has all the latest bug fixes/additions. There typically is a review of dev env and certain features/bugs are deemed stable, at which point i merge those specific feature into trunk. Others are reviewed and may need some more work, in which case I go into the specific branch and make adjustments.

The pain that I am feeling is that I have dev and trunk and I have to merge feature/bug branches into each. Just seems so complex and cumbersome. Am I doing it right, is there a better way/practice, easier practice? Or am I doing it totally wrong, in which case I need a better way!

Answer 1

I prefer this scenario:

• Develop in trunk for trivial changes, or in a feature/bugfix branch for larger pieces of work.
• Also have branches for environments, and released versions. e.g. "production", "stage"
• Tags should be final, i.e. don't commit to a tag.

So, an example lifecycle:

Development

• Do some developent in trunk, and in branches bug-1, bug-2, feature-1 and feature-2. Once you have verified the bugs and features, merge the stable ones into the trunk (e.g. merge bug-1, bug-2 and feature-1).

Feature complete:

• Once you are ready to stage the code you can branch the trunk into the branch "stage", any code that used to be in stage will be replaced by the trunk code. A stage system always runs a build of the stage code so you can test. Development can continue in the trunk and the feature/bug branches.

Release:

• Once the stage branch is stable enough you can branch it to a release branch. Branch it to a branch called "release-1.X" and now tag this revision as "release-1.0.0". The production server can run a build of the release-1.0.0 tag. Do not commit anything to this tag.

Bugfix:

• If you notice a bug in the production code, you can fix it in the trunk, merge the fix through the stages up to the 1.X release branch, and then tag the fixed release version as 1.0.1 and instruct the production servers to run a build of this new version.

Answer 2

To be honest your practice seems fine to me, having said that if a bug is not going to take to much time / code then I would suggest just checking out the dev and making the fix there and then just checking the fix right into the repository dev.

Also is there a reason you need an always stable trunk? How often are the developers breaking the dev that you need to make sure you always have a stable trunk? You should remove the dev part of the equation and just check everything into the trunk and then make sure the trunk gets fixed asap if broken. This will make the development process much easier. Just a thought to make your life easier.