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/