Revision controlINF5750/9750 - Lecture 1 (Part III)

Problem area

● Software projects with multiple developers need to coordinate and synchronize the source code

Approaches to version control

● Work on same computer and take turns coding○ Nah...

● Send files by e-mail or put them online○ Lots of manual work

● Put files on a shared disk○ Files get overwritten or deleted

and work is lost, lots of direct coordination

● In short: Error prone and inefficient

The preferred solution● Use a revision control system. RCS - software that

allows for multiple developers to work on the same codebase in a coordinated fashion

● History of Revision Control Systems:○ File versioning tools, e.g. SCCS, RCS○ Central Style - tree versioning tools. e.g. CVS○ Central Style 2 - tree versioning tools e.g. SVN○ Distributed style - tree versioning tools e.g. Bazaar

● Modern DVCS include Git, Mercurial, Bazaar

Which system in this course?

● In this course we will be using GIT as the version control system

● We will use the UIO git system, but you can also make git accounts on github.com or bitbucket for your own projects

● DHIS2 uses a different system: Launchpad/Bazaar

How it works

Repository:Central storage of the source code at a server

Working tree:Local copy of the source code residing on the developer’s computer (a client)

synchronize

synchronize

Commit

Centralized De-centralized

Commit locally

The repository

● Remembers every change ever written to it (called commits)

● You can have a central or local repository. ○ Central = big server in cloud○ Local = on your harddisk

● Clients can check out an independent, private copy of the filesystem called a working tree

Central

Local

Working tree

● Ordinary directory tree● Root directory has a hidden

administrative .git directory, containing your local repository

● Changes are not incorporated orpublished until you tell it to do so

Revisions● Every commit creates a new revision, which

is identified by a unique revision id● A revision identifier refers to a specific state

of a branch’s history forms a revision history

● Every revision can be checked out ● Can roll back current revision

Trunk and Branches● Trunk is the original main line of development (also a

branch, just called trunk for historical reasons)● A branch is a copy of trunk which exists independently

and is maintained separately● Useful in several situations:

○ Large modifications which takes long time and affects other parts of the system (safety, flexibility, transparency)

○ Different versions for production and development○ Customised versions for different requirements

Trunk

Branch 1Branch 3

Branch 2

Conflicts

● Arises if several developers edit the same part of a file● Git will try to auto-merge● If not, you have to resolve conflicts manually

1) Developer A makes a change to Code.java and commits

3) Developer B updates his working copy. He will be noticed that Code.java is in a state of conflict.

4) Developer B edits and resolves the conflicts, and commits the file back in the repository

2) Developer B makes a change to Code.java and tries to commit, but gets an ”out-of-date” warning.

Advantages of Revision Control Systems (RCS)

● Concurrent development by multiple developers

● Possible to roll-back to earlier versions if development reaches a dead-end

● Allows for multiple versions (branches) of a system

● Logs useful for finding bugs and monitoring the development process

● Works as back-up

Good practises

● Update, build, test, then commit○ Do not break the checked in copy

● Update out of habit before you start editing○ Reduce your risk for integration problems

● Commit often○ Reduce others risk for integration

problems● Check changes (diff) before committing

○ Don’t commit unwanted code in the repo

What to add to the repository

● Source code including tests● Resources like configuration files

● What not to add:○ Compiled classes / binaries (target folder)○ IDE project files○ Third party libraries

● Add sources, not products (generated files)!● Use a .gitignore file to tell Git which files to

ignore

Git Intro

● There are a number of GIT service providers: github.com and bitbucket.com are some examples

● Git is a distributed repository system. You have your own full copy of the repository on your disk.

● Read this: http://git-scm.com/book/en/Getting-Started-Git-Basics

Only changed files are checked in

Files can exist in 3 states

This repository is typically your local repository. You then push the local repository to the remote repository.

Set up GIT

● Install GIT on your computer● Then set it up to know who you are$ git config --global user.name "John Doe"$ git config --global user.email johndoe@uio.no

● Get some help$ git help <verb>

● Create an SSH key and post the public part to the web form in assignment 1

www.uio.no/tjenester/it/maskin/filer/versjonskontroll/git-wild.html

Creating an SSH key

As soon as possible, generate an SSH private key, and submit the public part of this using the following form:https://docs.google.com/a/roland.bz/forms/d/1bfHtcv_EyoGPyQjI2dRTIy_lf1lKPbVUMifjcX8C20Q/viewformMore information on how to generate a public/private key pair can be found here: https://help.github.com/articles/generating-ssh-keys Keep the private part of your SSH key private and safe. It will be used to log into the UIO git service. If you’re using Windows, use git-bash in git-for-windows as your terminal.

Creating a repository locally

You can create a local repository without linking to an external repository. $ git init$ git add *.c$ git add README$ git commit -m 'initial project version'Link to external repository$ git remote add origin <remote location>$ git fetch origin

Adding files to existing repository

● Create a new online repository by cloning a non-existing one. It will be created 4 u.

$ git clone gitolite@git.uio.no:inf5750/USER/REPO(if files already exist on your disk, you need to run git init and git fetch instead. See assignment 1)

● Then add files to the local repository and commit into local repository

$ git add existing_file.c$ git add another_existing.c$ git commit -m 'Some files'$ git status

File life cycle

Pushing your code to the central repository

Remote locations

Cloning a central repository into your rep$ git clone <git-address>Pulling changes and merge from the central repository into your rep$ git pull origin master (get data & merge)

Pushing your changes into the central repository$ git push origin master (push local repository to original online rep)

Remote locations reference

$ git clone git://github.com/schacon/ticgit.git$ git remote -v$ git fetch [remote-name] (fetches data from repository, no merge)$ git fetch origin (fetch data from original cloned rep, but no merge)$ git pull origin master (fetches data AND merges)$ git push [remote-name] [branch-name]$ git push origin master (push local repository to original online rep)$ git remote show origin

Tags

You can use tags to mark specific versions of the code. List tags:$ git tagCreating a tag$ git tag -a v1.4 -m 'my version 1.4'Showing tag info$ git show v1.4Push tag to central rep (tag names are not pushed by default)$ git push origin v1.5

Some useful commands

$ git log$ git status$ git mv <file> <file> (moving a file)$ git rm <file> (rmoving a file from the repository)$ git commit --amend (adding some more files to a commit)$ git reset HEAD <file> (unstage a file)$ git checkout -- <file> (revert a file - bring back the repository copy)

Branching

A branch is a ‘separate thread’ of code you can work on in parallelCreate a branch (you’ll still be working on the old branch) $ git branch <branchname>Selecting a branch$ git checkout <branchname>Merging branch1 into the branch you are in now$ git merge <branch1>

Pull requests

● For many open source projects, new developers will not have push access.

● You need to create a branch where you place your revised code, put this on a central repository and send the link of this branch to the open source project.

● They will review your code (by pulling it into their local repository) and merge it into the main code-base if they find it useful etc.

UIO’s git server

For more info on UIO’s git server, check out http://www.uio.no/tjenester/it/maskin/filer/versjonskontroll/git-wild.html (Norwegian)Read up on permissions (how to make available on web or to another user). Those especially interested can also read: http://gitolite.com/gitolite/wild.html

Ignoring files

Create a “.gitignore” file

*.class

# Package Files #

*.jar

*.war

*.ear

References

http://git-scm.com/book http://marklodato.github.io/visual-git-guide/index-en.html

Bazaar

The following slides are kept for reference if you need to access the DHIS2 system using the Bazaar/Launchpad RCS system.The course sticks to using Git as much as possible, because this is now more common for open source projects. Bazaar is also a good system, but has some quirks that students have struggled with in the past.

Work cycle (Centralized way)Initial check out:The developer checks out the source code from the repository

3) Commit:The developer makes changes and writes or merges them back into the repository

2) Update:The developer receives changes made by other developers and synchronizes his local working copy with the repositoryResolve conflicts:When a developer has made local changes that won’t merge nicely with other changes, conflicts must be manually resolved

1) Development:The developer makeschanges to theworking copy

Repository

Example remote repository locations:

lp:~<user>/<project>/<branch-name>

lp:~<user>/dhis2-academy/<branch-name>

lp:~<user>/+junk/<branch-name>

Starting a new repository$ bzr init lp:~user/dhis2-academy/branch-name$ bzr checkout lp:~user/dhis2-academy/branch-name$ bzr add (adds files)$ bzr commit -m “My first files”You can also create a remote repository by doing a local ‘bzr init’ and then a ‘push <remote-repository>’, but you should avoid using push, at least until you know what you’re doing.‘bzr push’ replaces the central repository with your own, so it can erase what is stored centrally.We may cover more use of distributed bazaar repositories later in the course if there is interest.

Getting code from an existing repository

$ bzr checkout lp:~user/dhis2-academy/branch-name(Edit project. Time passes.)$ bzr add $ bzr update (download any changed files)(resolve conflicts either automatically or manually)$ bzr commit -m “Second commit”

● Now your files are in the central repository● This is not using the decentralized way to do it● Instead of bzr checkout, you could use first bzr branch

<repo-url> and then bzr bind <repo-url>.

Making changes to a repositoryAssume that you’ve done either “bzr checkout <repository>” or “bzr merge <repository” + “bzr bind <repository>”

$ bzr update (it’ll try to auto-merge changes)$ bzr add (adds new files)$ bzr commit -m “My first files”

(it may also discover conflicts and give an error message, forcing you to do bzr update and manually look through files and fix marked changes)

Decentralized - two ways

Bind and unbind

Remoterepository

Localrepository

Working tree

“bzr commit”

if bound to central

repository

if bound to local

repository

$ bzr unbindor after

$ branch <repository>

$ bzr bind <repository>

or$ checkout

<repository>

Working decentralizedYou can commit locally, if you don’t want to upload to the central repository. For example if your project doesn’t compile, you should never upload to the central repository.

$ bzr commit --local -m “Some revisions” $ bzr commit --local -m “Some more revisions” (these will be stored locally)… then later … $ bzr commit -m “Stored centrally”

In the above example, you are still bound to the central repository, but you are not using it for all commits.

Creating your own branch(not bound to central repository)$ bzr branch lp:~user/dhis2-academy/branch-name

● You are now in distributed mode. ● If you run ‘bzr commit’ now, your changes will not be

checked into the central repository. ● This is great for checking out projects that you want to

play with, but you are not planning to contribute to immediately.

● If you want to contribute some of your source-code, you can bind, merge etc… Or check out with ‘bzr checkout’ in a separate directory, merge your changes in there and then update from the new directory.

Working decentralizedYou can unbind from the central repository

$ bzr unbind (now you’re on your own)… edit files …$ bzr update$ bzr commit -m “My first files” (these will be stored locally)…$ bzr bind <central repository>$ bzr update$ bzr commit -m “Stored centrally”

Bazaar offline commands

Add a file to the working copy:$ bzr add Code.java

Delete a file from the working copy:$ bzr remove Code.java

Compare working copy with repository on file-level:$ bzr status

Compare working copy with repository on code-level:$ bzr diff

Revert a file to the state from last commit$ bzr revert Code.java

Tell bazaar that you’ve manually fixed a failed merge$ bzr resolve Code.java (then do bzr commit afterwards)

Summary

● Revision control systems enable multiple developers to work on the same code base

● Bazaar uses a client/server system with a repository and working copies

● Every commit generates a new revision, which can be checked out independently

● Projects have a main branch, but can have multiple branches

Resources

https://help.launchpad.net/Code

http://doc.bazaar.canonical.com/latest/en/tutorials/using_bazaar_with_launchpad.html

http://doc.bazaar.canonical.com/bzr.2.6/en/tutorials/tutorial.html

http://doc.bazaar.canonical.com/latest/en/_static/en/bzr-en-quick-reference.pdf

Work cycle - Distributed way● Several ways to work decentralized● Create a local branch - “bzr branch …”● Work locally● Then pull central changes into your own

repository● Then merge and push your own repository

to the cent● or● Check out code● Do local commits using ‘bzr commit --local’● Run update to get new changes● Commit into central repository

Working offline for a long time