The following informations present an overview what branching in CVS exactly is. It is not an hands-on documentation, hence there are no real CVS commands printed, but you will get a picture and then check the CVS manual :)
![[Important]](images/admonitions/important.png) | Important |
|---|---|
The information about different branches being available for more.gorupware ist not correct (any longer, right now). All development takes place on the trunk and there are no stable and development releases. This will stay this way until a 1.0 release is out. Then we will switch to this approach. Keep this in mind! | |
moregroupware right now has one branch and of course one trunk, the trunk is the main development line, which each CVS project has. Below something trying to visualize this.
_______________ Branch
/
/
------------------------- Trunk
A branch will be split when a major stable release comes out, for example 0.4.0 or 0.6.0 or 0.8.0 or 1.0.0 or 1.2.0 ... You can see that in Moregroupware the second versionnumber indicates wheter it is a stable release (number is even). Major releases have a 0 in the third versionnumber. Minor stable releases are for example 0.4.2 or 0.6.8. A minor release is just a patch on the major release, increasing one number by each minor release.
In contrast all second numbers which are odd are the developer releases. For example 0.5.0 or 0.7.0 are major developer releases. 0.5.1 or 0.7.5 were Minor developer releases. So the same system as for stable releases.
So why branching when a stable Major release comes out. This is easy. Assume you release 0.4.0 and after two weeks some bugs will be reported. Normally you would fix the bugs and make a minor stable release for example 0.4.1, but what if you had started to develop some major improvements in your product during the last 2 weeks?
Now you cant integrate your bug fixes and release them, because you have a very unstable or totally unfunctional new feature in the source code, which would also be released. So what to do, wait until the big new feature is also integrated perfectly? NO.
Instead you make a branch after the major stable release 0.4.0 and fix/commit your bugs only in this branch. This means, when you commit bugfixes, they will only be in the branch. In the meantime you can develop t he big new features into your main development line (trunk) without the problem of interferance with bugfixes. When you made some bugfixes, just do a release for example 0.4.1 on the branch, means the new feature which is still broken wont be released, because the branch dont know this code.
So far so good. The last thing you must handle is the merging of your bugfixes in the trunk. Because it would be silly to do bugfixes two times, one time in your branch and one time in your trunk. So at some point in your branch, you decide to merge the changes from the branch into the trunk. In CVS its just a update with some more parameters. Details you will find in CVS docs around the world.
Bugfixes
_____|_______________ Branch
/ .
/ .MERGE(*1)
------------------------------- Trunk
| |
betacode +bugfixes
You can see that after a while (and after the bugfixes of course) the user decided to merge the changes (the bugfixes) into the trunk. From now on, the bugfixes are also in your main development line.
If you want to merge several times within one branch into the trunk, you must set a tag on the branch indicating that some merge was done. The next time you merge into the trunk, you define that the merge should start from the tag you set before, this way things won't get re-merged over and over again.