Sander Soo

2

Make yourself more efficient

Find types faster Type filters

Find resources faster

Refactor code faster And with less errors

Quick fix

Quick search e.g. plugin: Quick Search for Eclipse

Code autocompletion

Copy/delete/move lines faster

...

3

Find usages of a piece of code ...in a smarter way than manual labour

Code templates Never manually write e.g., main method

Formatting Glue between IDE and versioning

Must be same for ALL developers

Save actions

Debugging Remote debugging

Shown in labs

Breakpoints

e.g. Exception breakpoints

Inspect expressions

Force return

...

4

Ever made a change to a piece of code, realized it was a mistake, wanted to „undo“ to a specific previous point in time?

Computer failed, no backup?

Ever start to wonder why a problem in code is solved the way it is?

Ever want to try out some new functionality, without breaking the current main state?

Want to make money? Client wants some functionality now (will pay big $$$)

Client wants a bug fix to the thing you deployed to them 2 weeks ago (will pay even bigger $$$)

No new functionality/changes should be present

Would want to be able to make changes in parallel ($$$ + $$$)

Would want bug fixes to the old to also get to the new (painlessly)

....

5

a system for managing multiple revisions of the same unit of information

a system that records changes to a file or set of files over time so that you can recall specific versions later

Manual management – error prone Noone wants to do this in any larger scale

Ever

Automatic Less errors & deterministic

faster & better

6

Centralized

Exists a single central copy

Developers will commit code (record changes) to this central

Any commit is immediately seen in central

No local history

Central server fails – all changesets are gone

Distributed

Every developer will clone their very own copy

Developers will commit code first to their own local copy

Pull and push will download and upload changes to/from central (central not required)

Full local history with all metadata of original

Central fails – no prob, make new central, push, done

7

Subversion (SVN) Central version control

No, we don’t want this

Git Distributed

Staging area

Mutable mindset for history

...

Mercurial Distributed

Tracking index

Immutable mindset for history

...

Other options: Dropbox and a ball

8

Dependent of exact version control system used

Add – add files to index/stage

Commit – snapshot of a set of changes

Push – upload changes to remote

Pull – get remote changes

Update/Checkout – view older revision of file or commit/update to branch

Branch – handle independent lines of development (create,read,rename,delete)

Merge – integrate independent lines of development into one

Rebase – move a branch to a new base

Tag – mark commit with additional info (e.g. release-1.0)

...

9

New project

Make changes

Version the changes

10

So you decided to push code

So did some of your friends (developing same app)

You both changed the same methods

You both changed the same lines of code

You both changed the same 47 files

You both changed the same 147 methods

You both created files with same name in same package

See where this is going . . .

Fastest way to hell is if there exists a strict standard of doing things :D You should still follow this standard

You should also communicate with other developers

so problems happen as rarely as possible

(Can show that code is too coupled or tasks partitioned suboptimally)

11

Like branches in a tree (sort of)

For a (diverged) line of development

Branch

Make some changes

Merge

A list of changesets

Ideally has a name and a purpose

Is isolated from other branches

To join branches - merge

12

Each have their own copy

Everyone pushes to single repository

No branches

Pull/Push features

Rebase/merge if something changed inbetween

13

Each have their own copy

Everyone pushes to single repository

All feature developers should take their own feature branch

Large feature also has substeps/features that we also want to version

In theory, master branch will never contain broken code

Pull request and code reviews

Code merged when it is checked and verified by peers

14

15

16