{numberedheadings}
{toc}
h1. Commit Access
h2. Configuration
The subversion server uses SSL client certificates to handle authentication of users. When you are granted commit access, you will be provided two files. These files should be placed in your {{~/.subversion/}} directory.
# [Digium_SVN-cacert-sha1.pem|http://svnview.digium.com/svn/repotools/Digium_SVN-cacert-sha1.pem]
# <name>-cert.p12
The following should be placed in the {{~/.subversion/servers}} file:
{code:title=~/.subversion/servers}
[groups]
digium = *.digium.com
[digium]
ssl-client-cert-file = /home/_<username>_/.subversion/_<name>_-cert.p12
[global]
ssl-authority-files = /home/_<username>_/.subversion/Digium_SVN-cacert-sha1.pem
{code}
It is also recommended that you add the following to the {{~/.subversion/config}} file. Otherwise, you will have problems using our tools for merging changes between branches.
{code:title=~/.subversion/config}
[miscellany]
interactive-conflicts=no
{code}
h2. SVN Checkouts
Checkouts that come from {{http://svn.asterisk.org/}} are read-only copies of the repositories. When doing a checkout that you intend to commit to, it must be from {{https://origsvn.digium.com/}}. For example:
{code:bash}
$ svn co https://origsvn.digium.com/svn/asterisk/trunk
{code}
h1. Using {{svnmerge}} for Cross-Branch Merging
h2. Tools Installation
You must install {{svnmerge}} and the related wrappers from our {{repotools}} repository. The wrapper scripts use {{expect}}, so be sure to install that, too.
{code:bash}
$ svn co http://svn.asterisk.org/svn/repotools
$ cd repotools
$ ./configure
$ sudo make install
{code}
h2. {{svnmerge}} Properties
If you do a {{svn pl -v}} while you are located in an svn checkout, you will see all the properties currently attached to the root directory. For instance, on a checked out copy of Asterisk trunk, you will see something like this:
{noformat}
branch-1.8-blocked
/branches/1.8:
branch-1.8-merged
/branches/1.8:1-279056,279113,279227,279273,279280,...............,286457
{noformat}
and on the 1.8 branch, you will see these sort of properties:
{noformat}
branch-1.6.2-blocked
/branches/1.6.2:279852,279883,280227,280556,280812,282668
branch-1.6.2-merged
/branches/1.6.2:1-279056,279207,279501,279561,279597,279609,....................,286268
{noformat}
These properties identify the following things:
# The branch changes are being merged from
** {{branch-<branch>-...}}
# The revisions merged from that branch
** {{branch-<branch>-merged:/branches/<branch>:<revisions>}}
# The revision explicitly not merged, or blocked, from that branch
** {{branch-<branch>-blocked:/branches/<branch>:<revisions>}}
h2. Branch Merging Order
When committing a change that applies to more than one branch, the change first goes into the oldest branch and is then merged up to the next one. If a branch is reached where the change should not be merged up, it should be explicitly blocked. The following diagram shows the current branch merge order.
{section}
{column:width=25%}
{flowchart}
"/svn/asterisk/branches/1.8" -> "/svn/asterisk/branches/1.10"
"/svn/asterisk/branches/1.10" -> "/svn/asterisk/trunk"
{flowchart}
{column}
{column:width=75%}
* 1.2 -> 1.4
** {{merge24 _<revision>_}}
** {{block24 _<revision>_}}
* 1.4 -> 1.6.2
** {{merge46 _<revision>_}}
** {{block46 _<revision>_}}
* 1.6.2 -> 1.8 ** {{merge68 _<revision>_}}
** {{block68 _<revision>_}}
* 1.8 -> 1.10
** {{merge810 _<revision>_}}
** {{block810 _<revision>_}}
* 1.10 -> trunk
** {{merge10trunk _<revision>_}}
** {{block10trunk _<revision>_}}
{tip}
All of these scripts create a commit message for you in the file {{../merge.msg}}. Run {{svn commit}} and use that commit message with the following command:
{code:bash}
$ svn commit -F ../merge.msg
{code}
{tip}
{tip}
Sometimes when you go to commit your changes after merging from another branch, you will end up with a conflict. The conflict will typically be against {{.}} (period). To resolve the conflict, run {{svn resolved .}} prior to committing.
{tip}
{column}
{section}
h2. Backporting Changes
Sometimes a change is made in a branch and later it is decided that it should be backported to an older branch. For example, a change may have gone into the 1.8 branch and later needs to be backported to the 1.6.2 branch. To handle this, first manually make the change and commit to the 1.6.2 branch. Then, there is another wrapper similar to {{merge68}} and {{block68}} to record that the code from a revision already exists in the 1.8 branch. The wrapper is {{record68}}.
{code:bash}
$ cd 1.8
$ record68 <revision>
$ svn commit -F ../merge.msg
{code}
h1. Developer Branches
{info}
If you have been granted workspace on the server, you will have read and [electronically signed the Open Source Contributor License|https://issues.asterisk.org/] found at https://issues.asterisk.org (upon signing in) and have been given an SSL client certificate.
{info}
Developer branches are stored in the {{/team/<name>}} directory of each project repository (and {{/team/<name>/private}} for private branches).
h2. Creating a Developer Branch
Use the following commands to create a branch and prepare it for future merge tracking of the branch you created it from. This example creates a branch off of Asterisk trunk.
{code:bash}
$ svn copy https://origsvn.digium.com/svn/asterisk/trunk https://origsvn.digium.com/svn/asterisk/team/jdoe/my-fun-branch
$ svn checkout https://origsvn.digium.com/svn/asterisk/team/jdoe/my-fun-branch
$ cd my-fun-branch
$ svnmerge init
$ svn commit -F svnmerge-commit-message.txt
{code}
h2. Group Branches
Group branches are developer branches intended to be worked on by more than one developer. Instead of putting them in {{/team/<name>}}, they go in the {{/team/group}} directory, instead. Otherwise, they're managed in the exact same way as other developer branches.
h2. Automatically Keeping Branches Up to Date Using {{automerge}}
Our subversion server provides the ability to automatically keep developer branches up to date with their parent. To enable this feature, set the {{automerge}} and {{automerge-email}} properties on the root directory. Changes from the parent branch will be periodically (once an hour) merged into your branch. If a change from upstream conflicts with changes in the branch, the {{automerge}} process will stop and the address(es) listed in the {{automerge-email}} property will be notified.
{note}
Running {{svnmerge init}} and committing those properties is a prerequisite for {{automerge}} to work for a developer branch.
{note}
Use the following commands to enable automerge on a developer branch:
{code:bash}
$ cd my-fun-branch
$ svn ps automerge '*' .
$ svn ps automerge-email '[email protected]' .
$ svn commit "initialize automerge"
{code}
h3. Setting {{automerge-email}} on a Group Branch
For a branch with multiple developers working on it, it may be useful to have automerge emails sent to more than one email address. To do so, just separate the email addresses in the property with commas. The value of this property is literally used as the content for the {{To:}} header of the email.
{code:bash}
$ svn ps automerge-email '[email protected],[email protected],[email protected]' .
{code}
h3. Resolving {{automerge}} Conflicts
If your developer branch goes into conflict with {{automerge}} on, and the {{automerge-email}} property has been set, you will receive an email notifying you of the conflict and {{automerge}} will be disabled. To resolve it, use the following commands:
{code:bash}
$ cd my-branch
$ svn update
$ svnmerge merge
{code}
Running the {{svnmerge}} tool will merge in the changes that cause your branch to go into conflict into your local copy. Edit the files that are in conflict to resolve the problems as appropriate. Finally, tell SVN that you have resolved the problem, re-enable automerge, and commit.
{code:bash}
$ svn resolved path/to/conflicted/file
$ svn ps automerge '*' .
$ svn commit -m "resolve conflict, enable automerge"
{code}
h2. Private Branches
A private developer branch is only visible to Digium and the branch owner. Management of a private branch is exactly the same as any other developer branch. The only difference is branch location. Instead of putting the branch in {{/team/<name>/}} the branch goes in {{/team/<name>/private/}}.
h2. Merging a Developer Branch into {{trunk}}
{info}
If your branch contains new functionality, please make sure you have made the appropriate modifications to {{CHANGES}} and/or {{UPGRADE.txt}}.
{info}
If a developer has a branch that is ready to be merged back into the trunk, here is the process:
{code:bash}
$ svn co https://origsvn.digium.com/svn/asterisk/trunk
$ cd trunk
$ svn merge --ignore-ancestry https://origsvn.digium.com/svn/asterisk/trunk https://origsvn.digium.com/svn/asterisk/team/jdoe/bug12345 .
{code}
{note}
This is NOT using the svnmerge script; this is just a normal SVN merge.
{note}
Once this is done, the working copy will contain the trunk plus the changes from the developer branch. If you follow the above instructions for creating branches, you have probably introduced properties to the root of the branch that need to be removed.
{code:bash}
$ svn revert .
{code}
If you are purposely introducing new properties, or purposely introducing new values for existing properties, then you might do the following instead, so as not to destroy your properties:
{code:bash}
$ svn pd svnmerge-integrated .
$ svn pd automerge .
$ svn pd automerge-email .
{code}
If everything merged cleanly, you can test compile and then:
{code:bash}
$ svn commit -m "Merge branch for issue 12345"
{code}
Once the contents of your branch has been merged, please use {{svn remove}} to remove it from the repository. It will still be accessible if needed by looking back in the repository history if needed.
{numberedheadings} |