Revision control
INF5750/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 Working tree: Local copy of the source code Repository: residing on the Central storage of developer’s the source code at computer (a client) a server
synchronize synchronize
Commit Commit locally
Centralized De-centralized The repository Central
● 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 Local Working tree
● Ordinary directory tree ● Root directory has a hidden administrative .git directory, containing your local repository ● Changes are not incorporated or published 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
Branch 3 Branch 1 Trunk
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
2) Developer B makes a change to Code.java and 1) Developer A makes a tries to commit, but gets an change to Code.java ”out-of-date” warning. and commits 4) Developer B edits 3) Developer B updates and resolves the his working copy. He will conflicts, and commits be noticed that Code. the file back in the java is in a state of repository conflict. 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 [email protected] ● Get some help $ git help
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_lf1lKPbVUMifjcX8C 20Q/viewform More 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
● Create a new online repository by cloning a non-existing one. It will be created 4 u. $ git clone [email protected]: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 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 tag Creating a tag $ git tag -a v1.4 -m 'my version 1.4' Showing tag info $ git show v1.4 Push 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
A branch is a ‘separate thread’ of code you can work on in parallel Create a branch (you’ll still be working on the old branch) $ git branch
● 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/gi t-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: 1) Development: 2) Update: The developer The developer makes The developer receives checks out the changes to the changes made by other source code from working copy developers and the repository synchronizes his local working copy with the repository Resolve conflicts: When a developer has made local changes that won’t merge nicely with other changes, conflicts must be manually resolved 3) Commit: The developer makes changes and writes or merges them back into the repository Repository
Example remote repository locations: lp:~
$ 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
$ 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
Assume that you’ve done either “bzr checkout
$ 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
if bound to central repository
“bzr commit”
Remote Working repository tree if bound to $ bzr bind local
You 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 decentralized
You 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
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_laun chpad.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