Development branch: Difference between revisions

Revision as of 21:29, 20 July 2012

When to create a development branch

You want to create a development branch any time the commit will be non-trivial. Trivial bugs can be fixed directly on the trunk, as long as you're confident that the change won't break anything else. Non-trivial includes many enhancements (any time the database is changed for sure, and any time you're changing an API function that is used elsewhere), and all quantum bugs.

How to name development branches

Name the development branch after the bug number. If you're working on bug 34, name the bug 34- and then something descriptive. For example, 34-div-layout is good.

How to actually do it

svn cp https://secure.regattadata.com/svn/trunk/rds https://secure.regattadata.com/svn/branches/rds/development/(your_branch_name)
cd /path/to/your/svn
svn switch https://secure.regattadata.com/svn/branches/rds/development/(your_branch_name)

BE SURE TO COMMENT YOUR BRANCH NICELY! I can't stress this enough. If you don't say something like "Make a new devel branch for bug 34, div layout" you'll never be able to find it later when you're going to merge the branch back into the trunk. To further help you remember what revision number to merge from, comment on the bug that you're fixing that you've created a branch, and that the revision number is the number returned from the svn cp command above.

Then document your branch on the existing branches page: Branches

Make all of your changes to the development branch. If you want someone else to look at your changes, assign the bug to that person and ask for a review. Be sure to post the branch name so it's easier for the reviewer to change to that branch. The reviewer can then "svn switch" to that branch, apply the database migrations, and test the code.

When you're done

Once the code is finished, assign the bug to an RDS driver and have them merge the code for you. The RDS drivers will confirm that the code is ready and merge the code.

Once the changes have been merged from your branch, that branch is officially closed and should not be used again.

@@ Line 15: / Line 15: @@
 BE SURE TO COMMENT YOUR BRANCH NICELY!  I can't stress this enough.  If you don't say something like "Make a new devel branch for bug 34, div layout" you'll never be able to find it later when you're going to merge the branch back into the trunk.  To further help you remember what revision number to merge from, comment on the bug that you're fixing that you've created a branch, and that the revision number is the number returned from the svn cp command above.
-Then document your branch on the existing branches page: [[Existing_branches]]
+Then document your branch on the existing branches page: [[Branches]]
 Make all of your changes to the development branch.  If you want someone else to look at your changes, assign the bug to that person and ask for a review.  Be sure to post the branch name so it's easier for the reviewer to change to that branch.  The reviewer can then "svn switch" to that branch, apply the database migrations, and test the code.