The Internet belongs to everyone. Let’s keep it that way.

Protect Net Neutrality
Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Version Control G52GRP Guest Lecture 2012

No description

Matthew Walton

on 29 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Version Control G52GRP Guest Lecture 2012

Version Control Branches and what came next Matthew Walton BSc (Hons) Computer Science, University of Nottingham 2003

Junior Software Engineer, CacheLogic, 2003-2005

Postgraduate Research Student, University of Nottingham, 2005-2007

Senior Software Engineer, Thomson Reuters, 2007-2011

Systems Developer, EvoEnergy, 2011-present

Developer, DutySheet, 2012-present There are many version control systems.

The fundamental thing they all share is tracking the state of a directory tree over time.

Where they usually differ is in how they deal with multiple contributors and branching. Branching Branching splits a repository into parallel streams.
Contributors can commit freely to both streams.
Changes from one branch can be merged into the other. trunk branch Types of branch 'Trunk'/'Master' - default branch, usually where most development work happens

'Feature branch' - develop a big, disruptive new feature without disturbing the rest of the team

'Release branch' - branch when you release a new version of your software. Provides a base for bugfix releases and minor updates Merging 'Merging' is the process of taking changes from one branch and applying them to another.

Feature branches usually have all their changes merged into trunk once the feature is complete.

Bug fixes on release branches are often merged into trunk if trunk exhibits the same bug. trunk feature A feature B release 1.0.0 feature C release 1.0.1 Branching in Subversion Subversion allows branches and merges between them

A branch is a logical copy of another branch at a particular revision or tag

'svn branch' creates new branches

'svn checkout' is given a branch name Branching in Subversion Subversion branches are fairly clunky

You have to make a new checkout to work with another branch

Subversion's merging and tracking of merges doesn't stand up very well in complex repositories with lots of developers introducing... DVCS Distributed Version Control Systems DVCS DVCS systems abandon the concept of a central repository

Instead, each checkout is actually a clone of the repository and contains its entire history and all branches DVCS Each developer makes commits to their local repository

From time to time, developers can pull commits from their colleagues' repositories into their own DVCS In practice, it often works better to have a central repository that everyone pushes to and pulls from

Because merging between repositories is how changes are shared, a DVCS has to be extremely good at it Git One of the most popular distributed systems today is Git

Git is open source and was originally developed by Linus Torvalds to manage the Linux kernel development process

Git is quite odd, but extremely powerful Git tags The tag 'master' represents the latest commit in what Subversion calls 'trunk'

Other branches have tags pointing to their own most recent commits

Users can create their own tags Git workflow git clone git://
cd myproject
git checkout -b feature-a
vim src/
git add src/
git commit -m "New feature A"
git checkout master
git merge feature-a
git push origin master master feature-a Branching models No matter what VCS you use you need a policy for branch management

Sometimes it's less important what that policy is than the simple fact of having one Resources git website (down at time of writing) extensive explanation of one branching model Subversion website The Subversion book (free to read online) Remotes You can track as many remote repositories as you like

Most commonly you only have one, called 'origin'

Origin's master branch is called origin/master Compatibility Git comes with support for Subversion repositories

'git svn' offers a set of commands which allow you to set up a Subversion repository as a remote branch

Git can push and pull to it Git everything is about commits a commit represents the state of the tree at a particular point in time commits are identified by hashes of their metadata git metadata is verifiable by recomputing these hashes commits can have multiple parents a multi-parent commit represents a merge between branches developers work on clones of the repository a clone contains the origin repository's entire history and all branches each clone can be thought of as an implicit branch other repositories are represented by 'remote tracking' branches
Full transcript