Subversion S/W CM
In software engineering, software configuration management (SCM or S/W CM) is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts.
This article represents the basic knowledge of Subversion CM needed for understand the Radix.Linux CM.
All repositories are placed at https://svn.radix.pro/svn/ .
- Main code trunk is located at https://svn.radix.pro/svn/build-system/trunk/
- Branches are located at https://svn.radix.pro/svn/build-system/branches/
- Main code trunk is located at https://svn.radix.pro/svn/platform/trunk/
- Branches are located at https://svn.radix.pro/svn/platform/branches/
- Main code trunk is located at https://svn.radix.pro/svn/toolchains/trunk/
- Branches are located at https://svn.radix.pro/svn/toolchains/branches/
- Each commit has a number unique within the whole repository https://svn.radix.pro/svn/toolchains/
- Each file/directory changed in some specific commit has the same number and can be identified as follows: https://svn.radix.pro/svn/toolchains/trunk/Makefile@88, where the revision number is indicated immediately after the @ character.
Trunk – is a very stable main line of Radix.Linux source code. Before committing to trunk the locally changed copy should be compiled without any errors and warnings.
Development branches can be created by team leaders and developers. There are several types of branches created according to project needs.
- Project (like as Allwinner: https://svn.radix.pro/svn/toolchains/branches/allwinner/
- Item (like some activity in the feature development)
- Bug Fixing (created to fix some bug(s))
- New branch creation from trunk
- Coding / bugfixing / debugging
- Rebasing to the HEAD of trunk
- Code Review / Approval
- Entering to the Merge Queue
- Rebasing to the newest HEAD of trunk, making sure there are no errors and no warnings, performing smoke tests
- Merge to the trunk
- Moving the branch to deadwood: https://svn.radix.pro/svn/toolchains/branches/deadwood/
Branch Creation Basics
The Feature, Item, and Bug Fixing branches are usualy created from trunk or project branch (see Fig.1).
The development branch can be created by following Subversion command:
[/home/user] $ svn cp https://svn.radix.pro/toolchains/trunk@B1 \ https://svn.radix.pro/toolchains/branches/allwinner \ -F ./message.txt
Where message.txt – is a file which contains the commit message. The commit message should be created from corresponded template and should contents exact information about revision of trunk from which the branch has been created:
Where the B1 – is a revision of the trunk from which the developer branch has been created.
Roughly the merge operation can be described as follows:
merge = diff + patch
Diff and patch operations are performed over both code and properties. See Fig.2.
To rebase the development branch the developer have to check out the clean copy of his branch and apply changes performed on the trunk from last rebase till current revision of the trunk. Please remember that the reverted commits should be skiped. The rebasing command seems like follow:
[/home/user] $ svn merge -rB1:B2 https://svn.radix.pro/svn/toolchains/trunk \ ./allwinner
Where the ./allwinner – is a localy checked out clean developer branch.
After merging the changes from trunk the developer have to tesolve conflicts and rebuild his branch and perform tests with this build to be sure that this merge didn't inject regression to the development branch.
Then developer can commit the changes to his branch by following commands:
[/home/user] $ svn ci ./allwinner -F ./message.txt
Where the message.txt file contains the following information:
The most important operation is the commit your changes to the trunk. Commit should be performed only in boundaries of time slot delegated where the development branch become the first in the Merge Queue. To make the commit we have to perform following operation:
- Check out the latest revision of trunk
- Apply the differences between head of trunk and head of development branch (Note: the branch should be rebased to the latest head of trunk) to the checked out local copy of trunk
- Build the changed local trunk
- Perform Smoke Tests
- Make the commit to the trunk only if Smoke Tests are passed without regression
Item 2 of this activities is shown at the Fig.3.
To apply the changes to the local checked out trunk you can make use following command:
[/home/user] $ svn merge \ https://svn.radix.pro/svn/toolchains/trunk@B2 \ https://svn.radix.pro/svn/toolchains/branches/allwinner@D3 \ ./trunk
After merging the changes to the local checked out trunk the developer have to resolve conflicts and rebuild the local copy of trunk. Then the developer have to perform Smoke Tests (see items 3, 4 above).
Only if Smoke Tests are passed without any errors the developer can commit the changes to the trunk using following command:
[/home/user] $ svn ci ./trunk -F ./message.txt
Where message.txt file contents whole information about this commit including the list of Polarion tickets which present in the Merge Queue:
This is almost all information which is necessary to work with the code of Radix.Linux .