why use branches in svn?

Question

i know that you could organize your files according to this structure in svn:

trunk branches tags

that you copy the trunk to a folder in branches if you want to have a seperate development line. later on you merge this branch back to trunk.

but i wonder why me and my group should do this. why should one copy the trunk to a branch and work with this copy just to merge it back to the trunk, and mean while the code is frequently updated/commited to stay in sync with the trunk. why not just work with the trunk then?

what is the benefits with creating a branch?

would be great if someone could shed a light on this topic.

thanks in advance

Answer 1

If you need to launch some releases when you achieve some milestone, you will find the branch is needed, you can define different branch for different release. its get more clearly about the code datebase、structure.... Do not you think it?

Answer 2

I have a blog post on this subject which might help shed additional light on when/why to use branches and exactly how they are implemented in Subversion. http://www.sublimesvn.com/blog/2009/11/what-are-branches-tags-and-trunk-in-subversion/

Answer 3

If you need to continue to support a v 2.0 product while you're working on a v 3.0 you'll need a branch of the v 2.0 which is separate from the v 3.0. Then you can have two different versions in simultaneous development without impinging upon each group's efforts.

Answer 4

The most important aspect of branching, in my opinion, is to allow you to be able to continuously release the trunk at regular intervals.

Branches allow your developers to take a task and work on it until it's finished, without hindering the launch of your next release. If a branch takes longer than originally planned to release, then you don't have to hold off the next version of your product before releasing.

I hope that helps :)

Answer 5

Imagine if you are working only with the trunk, and major changes are being committed and it will be 2 months before these changes are completed and tested for release. Now 3 weeks into this process, a critical bug is discovered in the last major release of the software. You need to implement a minor change to fix this bug, and the minor change needs to be based on the code that produced the last major release. However, all you have available is the trunk that has major untested changes in it. The best you can do is use date/times or tags to go back and try to create a copy of the source code that was used for the last major release.

Had you instead created a branch before working on the new features/changes for the 2 month release cycle, then the trunk would be untouched, and you could easily use the trunk, or branch again from the trunk, for implementing the critical bug fix and release. Additionally, when you merge the major changes back into the trunk, it will become apparent from the diffs that the minor bug fix had been implemented, and you can ensure it is integrated as well. Thus assuring that the "out of channel" critical bug fix is not reverted by the release of the next major version.