seem3490 information systems managementseem3490/slides/lecture08.pptx.pdfcreate a separate copy of a...

SEEM3490 Information Systems Management Lecture 08 – Version Control System

Prolog (1)

  Version Control is a very important concept in information sysmtes management. You’ve probably experienced using your own “Version Control System”.   For example, in your computer you may have:

  seem3490Project-v1.docx, seem3490Project-v2.docx, seem3490Project-copy.docx, bak1-seem3490Project.docx, …

  That’s the result of using “Save As”. You want to update a file, but also want to keep the old one. So what you have to do is:   Make a copy of the old file and rename it.

  We may even use a shared folder so other people can see and edit files without sending them over email.   Hopefully they also relabel the file after they save it.

Copyright (c) 2012. Gabriel Fung. All rights reserved.

Prolog (2)

  Our shared folder/naming system is fine for class projects or one-time papers.

  But for software projects (even only have a single developer)? Not a chance.

  Large, fast-changing projects (especially with many authors) need a sophisticated Version Control System to track changes and avoid general chaos.


Version Control System (VCS)

  A version control system allows you to track the history of a collection of files and includes the functionality to revert the collection of files to another version.

  Each version captures a snapshot of the files at a certain point in time. The collection of files is usually source code for a programming language but a typical version control system can put any type of file under version control.


Features of a VCS (1)

  A good VCS does the following:   Backup and Restore.

  Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.

  Synchronization.   Lets people share files and stay up-to-date with the latest version.

  Short-term undo.   Throw away your current changes and go back to the “last known

good” version in the database.

  Long-term undo.   Sometimes we mess up bad. Suppose you made a change a year ago,

and it had a bug. Jump back to the old version, and see what change was made that day.


Features of a VCS (2)

  Track Changes.   As files are updated, you can leave messages explaining why the

change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.

  Track Ownership.   A VCS tags every change with the name of the person who made it.

  Sandboxing. (Advanced Feature)   You can make temporary changes in an isolated area, test it first

before “checking in” (i.e. submit) your changes.

  Branching and merging. (Advanced Feature)   A larger sandbox. You can branch a copy of your code into a

separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.


Basic Setup

  Most version control systems involve the following setup (though the labels may be different):   Repository (repo)

  The database storing the files.

  Server   The computer storing the repo.

  Client   The computer connecting to the repo.

  Working Copy   Your local directory of files, where you make changes.

  Trunk   The primary location for code in the repo.


Basic Functions (1)

  All good VCS should provide these functions:   Add

  Put a file into the repo for the first time, i.e. begin tracking it with Version Control.

  Get Revision   What version a file is on (v1, v2, v3, etc.).

  Get Head   The latest revision in the repo.

  Check out   Download a file from the repo.

  Check in   Upload a file to the repository. The file gets a new revision number,

and people can “check out” the latest one.


Basic Functions (2)

Checkin Message   A short message describing what was changed.

Changelog/History   A list of changes made to a file since it was created.

  Sync   Synchronize your files with the latest from the repository. This lets

you grab the latest revisions of all files.

  Revert   Throw away your local changes and reload the latest version from

the repository.


Advance Functions (1)

  Some advanced functions provided by some advanced VCS:   Branch

  Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (“branch the code”) and a noun (“Which branch is it in?”).

  Find Difference/Change/Delta   Finding the differences between two files. Useful for seeing what

changed between revisions.

  Merge (or patch)   Apply the changes from one file to another, to bring it up-to-date.

For example, you can merge features from one branch into another.

  Check conflict:   When pending changes to a file contradict each other (both

changes cannot be applied).


Advance Functions (2)

  Resolve:   Fixing the changes that contradict each other and checking in the

correct version.

  Locking:   Taking control of a file so nobody else can edit it until you unlock

it. Some version control systems use this to avoid conflicts.

  Breaking the lock:   Forcibly unlocking a file so you can edit it. It may be needed if

someone locks a file and goes on vacation (or “calls in sick” the day Halo 3 comes out).


A Simple Scenario

  Alice adds a file shopping-list.txt to the repository.

  Alice checks out shopping-list.txt to her local working copy makes some changes

  Alice checks in shopping-list.txt with a checkin message “The bug xxxx is fixed”.

  The next morning, Bob synchronize his local working copy   Hence, the latest revision of shopping-list.txt is downloaded to his

local working copy.

  Bob can also browse the changelog, diff, etc to see what was changed and who changed shopping-list.txt.


Detail: Check In

  Each time we check in a new version, we get a new revision (r1, r2, r3, etc.).


Detail: Check In, Check Out and Edit (1)

  In reality, you will not keep checking in files. You may have to check out, edit and check in.


Detail: Check In, Check Out and Edit (2)

  Most version control systems store diffs rather than full copies of the file. This saves disk space. Also, the system can compare the differences between any two versions much more easy and efficiency.   For example, 4 revisions of a file doesn’t mean we have 4 copies;

we have 1 copy and 4 small diffs:


Detail: Branching

  Let us copy code into a separate folder without affecting the main trunk.   For example, we can create a branch for experimental ideas

  Depending on the VCS, creating a branch may change the revision number.

  Now since we’re in a separate branch, we can make changes and test in isolation, knowing our changes won’t hurt anyone. And our branch history is under version control.


Detail: Merging

  It try to merge a branch into a main trunk.   Very difficult!


Detail: Conflict (1)

  Many times, the VCS can automatically merge changes to different parts of a file. Conflicts can arise when changes appear   E.g., Joe wants to remove eggs and replace it with cheese (-eggs,

+cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

  At this point it’s a race: if Joe checks in first, that’s the change that goes through (and Sue can’t make her change).


Detail: Conflict (2)

  When changes overlap and contradict like this, the VCS may report a conflict and not let you check in.

  Usually, we can use the approaches to solve the dilemma:   Re-apply your changes.

  Sync to the the latest version (r4) and re-apply your changes to this file (e.g., add hot dog to the list that already has cheese.

  Override their changes with yours.   Check out the latest version (r4), copy over your version, and check

your version in. In effect, this removes cheese and replaces it with hot dog.


Real-life Example: Managing Windows


Distributed Version Control System (1)

  It usually does not have a central server.

  The user clone an existing repository.   Each cloned repository is a full copy of this repository. It

contains the full history of the collection of files and a cloned repository has the same functionality as the original repository.

  Every repository can exchange versions of the files with other repositories by transporting these changes.


Distributed Version Control System (2)

  Major differences from a centralized VCS:   Common operations (such as commits, viewing history, and

reverting changes) are fast, because there is no need to communicate with a central server.

  Communication is only necessary when sharing changes among other peers.

  Each working copy effectively functions as a remote backup of the codebase and of its change-history, protecting against data loss.

  Network is not involved for many common operations.


GIT

Git is a distributed version control system.

Git originates from the Linux kernel development and is used by many popular Open Source projects, e.g. the Android or the Eclipse developer teams, as well as many commercial organizations.


References

  Most contents are from: http://betterexplained.com/articles/a-visual-guide-to-version-control/

  Some important references: http://www.vogella.com/tutorials/Git/article.html


seem3490 information systems managementseem3490/slides/lecture08.pptx.pdfcreate a separate copy of a...

Documents