TeamMergeBranchPolicy

When doing the merge&branch, we will following the below principle.

The Branch-When-Needed system

(This is the system used by the Subversion project.)

 

• Users commit their day-to-day work on /trunk.
• Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
• Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
• Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

 

Scenarios

We have two scenarios which need us use the merge and branch commands.

1. Coding Tasks of Different Priority
   • We have two type of coding jobs, bug fixes and enhancement. In general, bug fix is urgent and can be fixed quickly by us. In this case, we need to do a quick deployment within a week. At the same time, the trunk might be used by another guy working on long term enhancement for another 2 weeks or 3 weeks. In this case, we have to do the bug fix on a branch and merge the changes later to trunk. This is the release branch mentioned in the svn reference manual.
2. Two persons working on the same type coding jobs.
   • This is the feature branch mentioned in the chapter 4 of svn reference manual. In this case, if two persons work on the enhancement or bug fix on the same application, we recommend they create their own branches for their own fix.

 

Solutions for Scenario: Two Engineers Work at BugFix on the Same Application.

For example, Larry has made a release plan containing bug Fixes on the application CD.He made a tracking bug 1234 which has bug12341, bug12342 and bug12343. The bug 12341 is assigned to Rui and 12342 and 12343 are for James. So the work flows are as below.

Let say the latest release is RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORY

• Create a Branch For Rui
  • svn copy http://svn.cnet.com/ebs/offline/CorporateDirectory/tags/RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORYhttp://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234-Rui -m "Create the branch from release RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORY for bug fix bug1234)"
• Create a Branch For James
  • svn copy http://svn.cnet.com/ebs/offline/CorporateDirectory/tags/RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORYhttp://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234-James -m "Create the branch from release RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORY for bug fix bug1234"
• Create a Branch to merge the changes from Rui and James later.
  • svn copy http://svn.cnet.com/ebs/offline/CorporateDirectory/tags/RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORYhttp://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234 -m "Create the branch from release RELEASE-20070510-092000-OFFLINE-CORPORATEDIRECTORY for bug fix bug1234"
• If the coding is done on any of sub-bugzilla ticket like bug12342, update issue tracker (bugzilla) with the branch information and saying you have done of the fix at this. So QA can take action on QA. If the QA is not passed. The developer has to continue this fix until it is fixed at last.
• When all the bug fixes are done for a person, the branch of that person can be merged into the branch BugFix-1234 by Larry. Let me take Rui's branch as an example.
  • Switch the Working Repository to the Branch BugFix-1234:
    • Go to your current working repository, then svn switch http://svn.cnet.com/ebs/offline/CorporateDirectory/branches/!BugFix-1234
  • Get the revision BASE of the branch by using svn log --verbose --stop-on-copy {branch_name}
  • Get the revision HEAD of the branch: svn update .
  • Merge the Rui's branch: svn merge -r{branch_base}:{branch_head} http://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234-Rui
  • Check the merge by using: svn status. ; svn diff ; Please the merge is not satifying, then use svn revert --cursively to roll back
  • If merge is OK then commit: svn commit -m "Merged BugFix-1234-Rui changes r{branch_base}:{branch_head} into the trunk."
  • Make a new release for this bug fix svn copy http://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234http://svn.cnet.com/ebs/offline/CorporateDirectory/tags/RELEASE-YYYYMMDD-HHMMSS-OFFLINE-CORPORATEDIRECTORY -m "Create a release from branches/BugFix-1234 "
  • Merge the branch to trunch * switch to trunk * svn merge r:{base}:{head} http://svn.cnet.com/ebs/offline/CorporateDirectory/branches/BugFix-1234 * check the merge * svn commit -m "Merged BugFix-1234 changes r{branch_base}:{branch_head}"

 

Solutions for Scenario: Two Engineers Work at Enhancement on the Same Application.

The difference btw. this scenario and the last scenario are as below.

• The name convention is different. In the bug fix, the branch name is BUGFIX-{BugNumber}-Username;whereas, in enhancement the branch name would be Ehancement-{BugNumber_-Username.
• The bug fix normally take little time. So we dont need to update the branch with the latest trunk information; whereas, the enhancement might take longer period. In this case, we need to update the branch with the changeset of trunk within every week.