An Introduction To Software
Development Using Python
Spring Semester, 2014
Class #10:
Branching
What Version Of Code Are You Working On Now?
V2.0
Image Credit: www.clker.com
Started
Here
Completed
Version 1.0
You Are
Here Now
The Problem With Bugs…
• Two things are going on at the same time: bugs are being found in released software (v1.0) and you are working on new features for upcoming software (v2.0).
• This will cause tensions – what should you be working on?
• You will need to work with the customer in order to balance these tensions.
Image Credit: www.clipartbest.com
How To Deal With Bugs
• Bugs in released software are generally a higher priority to customers than the new features that you are busy implementing.
• Bug fixes have to go two places: the released software (v1.0) and into the new, unreleased software (v2.0).
• In order to fix a bug you need to first be able to locate a specific version of your software and then make changes to that version without impacting your current development.
Image Credit: www.fotosearch.com
Say Hello To The “Trunk”
• By default, your version control softwaregives you code from the trunk.
• When you check out the code from your version control system, you’re checking it out from the trunk.
• That’s the latest code by default and (assuming people are committing their changes on a regular basis) has all of the latest bugs features.
Trunk
Image Credit: www.clker.com
What Happened To v1.0?
• Version control software stores ALL your code.
• Every time you commit code into your version control system, a revision number was attached to the software at that point.
• If you can figure out which revision of your software was released as Version 1.0, you’re good to go.
Image Credit: www.clipartpanda.com
It’s All In Your Comments
• Each time you check in software, you have an opportunity to include a comment.
• Each time you check in software, the software revision number gets incremented.
• You’ve got to figure out which features were in the software—in this case, for Version 1.0. Then, figure out which revision that matches up with.
Image Credit: www.prepare1.com
R1: Initial Import
R2: Added POKE support
R3: Merged picture support with Poke stuff.
R4: Quick bugfix for 1.0 release to handle cancelling the send picture dialog
R5: Tests and initial implementation of saving message log for Windows.
Steps Required To Fix A Bug In v1.0
• Check out the revision that created v1.0
• Make the bug fix
• Check the code back in
Note: You can’t check the code back in – you are
working on v2.0 and you’ve made a lot of changes
since the v1.0 code was created.
Your configuration management system is going to
barf all over you…
Image Credit: instafluxs.com
Solving The “Finding v1.0” Problem
• Most version control tools provide a better way of tracking which version corresponds to a meaningful event like a release or the end of an iteration. They’re called tags.
• Tag the initial 1.0 release, which is revision 4 from the repository in our example.
• Now instead of needing to know the revision number for version 1.0 and you can check out Version 1.0 of the code.
• A tag is a snapshot of your code at a certain time
Image Credit: www.123rf.com
Branches!
• A branch is a place where you’re working on code that isn’t in the main development tree of the code.
• We’ve tagged the 1.0 code, made fixes in a new branch, and still have current development happening in the trunk.
Trunk
Version 1
V2.0
Image Credit: www.clker.com
Trunks / Tags / Branches – Oh My!
• The trunk is where your active development should go; it should always represent the latest version of your software.
• A tag is a name attached to a specific revision of the items in your repository so that you can easily retrieve that revision later.
• Sometimes you might need to commit the same changes to a branch and the trunk if the change applies to both.
• Branches are copies of your code that you can make changes to without affecting code in the trunk. Branches often start from a tagged version of the code.
• Tags are static—you don’t commit changes into them. Branches are for changes that you don’t want in the trunk (or to keep code away from changes being made in the trunk).
Image Credit: www.dreamstime.com
The Right Way To Fix A Bug In v1.0
• First, check out the version 1.0 branch of the code.
• Fix the bug
• Commit the changes back into the branch.
• Note: Tags are snapshots of your code. You should always commit to a branch, and never to a tag
Image Credit: www.clipartpanda.com
What Do We Have Now?
• We now have two completely different sets of code: v1.0 and v2.0
• Our trunk directory in the repository has the latest and greatest code that’s still in development.
• We have a version 1.0 tag in our tags directory so we can pull out Version 1.0 whenever we want.
• We have a version 1 branch in our branches directory that has all of our critical patches that have to go out as a 1.x version without any of the new v2.0 development work.
Image Credit: www.clipartpanda.com
What Happens When We Create v1.1?
• When we actually do release v1.1 with thesepatches, we need to create a version 1.1 tag so we can get back to that version later ifwe have to.
Image Credit: www.clipartpanda.com
Trunk
Version 1
Version 1.1
To Branch Or Not To Branch?
Branch
• You have released a version of the software that you need to maintain outside of the main development cycle.
• You want to try some radical changes to code that you might needto throw away, and you don’t want to impact the rest of the team while you work on it.
Don’t Branch
• You can accomplish your goal by splitting code into different filesor libraries that can be built as appropriate on different platforms.
• You have a bunch of developers that can’t keep their code compiling inthe trunk so you try to give them their own sandbox to work in.
Branch only when you absolutely have to.
Each branch is a potentially large piece of software you have to
maintain, test, release, and keep up with. If you view branching as a
major decision that doesn’t happen often, you’re ahead of the game.
Image Credit: www.clipartpanda.com
Version Control Summary
What Version Control Does• Lets you create a repository to keep your
code in a single place to ease backup and recovery.
• Lets multiple people check out copies of the code and work efficiently as a team.
• Lets multiple people check changes back into the repository and distribute them to the rest of the team.
• Keeps track of who changes what, when, and why.
• Branches and tags code so you can find and change versions of code from way back when.
• Rolls back changes that never should have happened in the first place.
What Version Control Doesn’t Do
• Makes sure your code compiles.
• Tests code.
• Thinks for you.
• Makes sure your code is readable and well-written.
Image Credit: www.123rf.com
What We Covered Today
1. Versions
2. Bugs
3. Tags
4. Branches
Image Credit: http://www.tswdj.com/blog/2011/05/17/the-grooms-checklist/
What We’ll Be Covering Next Time
1. Building your code
Image Credit: http://merchantblog.thefind.com/2011/01/merchant-newsletter/resolve-to-take-advantage-of-these-5-e-commerce-trends/attachment/crystal-ball-fullsize/