version control *slides are modified from prof. necula from cs169

Version Control

*Slides are modified from Prof. Necula from CS169

Outline

• What is version control?– And why use it?– Scenarios

• Basic concepts– Projects– Branches– Merging

• conflicts

• Systems– CVS– Subversion

All Software Has Multiple Versions

• Different releases of a product

• Variations for different platforms– Hardware and software

• Versions within a development cycle– Test release with debugging code– Alpha, beta of final release

• Each time you edit a program

Version Control

• Version control tracks multiple versions

• In particular, allows– old versions to be recovered (for comparison,

tracking bug fixes, regressions)– multiple versions to exist simultaneously

Why Use Version Control?

• Because it is useful– You will want old/multiple versions– Without version control, can’t recreate project

history

• Because everyone else does– An essential software development tool

Version Control Systems

• Numerous version control systems are available– Commercial (ranging from $100-$4000+ per user):

• ClearCase• Microsoft Visual SourceSafe

– Open-source – free:• RCS (Revision Control System)• SCCS (Source Code Control System)• CVS (Concurrent Versions System)• Subversion

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Architecture of a Version Control System

• Centralized repositoryserves multiple clients

http://www.zefhemel.com/archives/2005/03/24/isdw-day-4-file-exchange

Scenario I – Fixing a bug

First release of your project to your customer

time

Rel

ease

1.0

Scenario I – Fixing a bug

Internal development, new releases to different customers

time

Rel

ease

1.0 1.3

Scenario I – Fixing a bug

A bug is discovered in 1.0 release need to make a fix, but 1.3 is not ready for release to the customer. A new version of 1.0 is made with the bug fix

Now there are two different development paths

time

Rel

ease

1.0 1.3

Bug fix for 1.0

Scenario I – Fixing a bug

Apply the bug fixes on 1.3 and make new release with the bug fixes

time

Rel

ease

1.0 1.3

Bug fix for 1.0

1.4

Scenario II – Development

Working on your project with your fellow developers

time

Rel

ease

1.4

Scenario II – Development

Every developer checks out a copy of the code at version 1.4

Local versions isolate developers from interfering with each other.

time

Rel

ease

1.4 1.4.a

1.4.b

1.4.n

Scenario II – DevelopmentAt the end of the day,

developers check in their code to create the version 1.5 of the project

The changes are now copied back to the version control system

With every commit most organizations run a test suite to make sure that a checked in code doesn’t break the whole system.

time

Rel

ease

1.4 1.4.a

1.4.b

1.4.n

1.5

Scenario III – DebuggingYou develop a system

through several versions.

At version 1.5 you discover there is a bug in your system

With version control you could checkout old versions of the system and find out in which version the bug was introduced.

time

Rel

ease

1.3 1.4 1.5

Concepts

• Projects

• Revisions

• Branches

• Merging

• Conflicts

Projects

A project is a set of files in version control

– Called a module in SVN

Version control doesn’t care what files– Not a build system– Or a test system– Just manages versions of a collection of files

Revisions

• Lets assume a project with only one file

• Consider– Check out a file– Edit it– Check the file back in

• This creates a new version of the file– Usually increment minor version number

• E.g., 1.5 -> 1.6

Revisions - II

• Most edits are small• For efficiency, don’t store entire new file

– Store diff with previous version– Minimizes space– Makes check-in, check-out potentially slower– Must apply diffs from all previous versions to compute

the current file

• Some systems have trouble with binary files– Store entire copies => inefficient

Revisions III

With each revision, system stores– The diffs for that version– The new minor version number– Other metadata

• Author• Time of check in• Log file message• Results of commit tests

checkoutupdatecheckindevelopment

Ideal development with SVN

repository

Developer A

Developer B

Merging

• Start with a file, say version 1.5

• Alice makes changes A to 1.5

• Bob makes changes B to 1.5

• Assume Bob checks in first– Current revision is 1.6 = apply(B,1.5)

Merging II

• Now Alice checks in– System notices that Alice had checked out 1.5– But current version is 1.6– Alice has not made her changes in the current version!

• The system complains– Alice is told to update her local copy of the code

• Alice does an update– This applies Bob’s changes B to Alice’s code

• Remember Alice’s code is apply(A,1.5)• Current version is 1.6 = apply(B, 1.5)

• Two possible outcomes of an update– Success– Conflicts

Merge - Success

• Assume that

apply(A,apply(B,1.5)) = apply(B,apply(A,1.5))

• Then order of changes didn’t matter– Same result whether Bob or Alice checks in first– The version control system is happy with this– Example: they both added a new method

• Alice can now check in her changes– Obtaining apply(A, 1.6) = apply(A, apply(B,1.5))

Merge - Failure

• Assume– apply(A,apply(B,1.5)) ≠ apply(B,apply(A,1.5))

• There is a conflict– The order of the changes matters– Version control will complain– Example: they changed the method signature

on the same method

checkin

X

Real development with SVN

repository

Developer A

Developer B

updateconflict resolutioncheckin

conflict

Conflicts

Conflicts arise when two programmers edit the same piece of code– One change overwrites another

1.5: a = b;

Alice: a = b++;

Bob: a = ++b;

The system doesn’t know what should be done, and so complains of a conflict.

Conflicts are Syntactic

• Conflict detection is based on “nearness” of changes– Changes to the same line will conflict– Changes to different lines will likely not

conflict

• Note: Lack of conflicts does not mean Alice’s and Bob’s changes work together

Example With No Conflict

Revision 1.5: int f(int a, int b) { … }Alice: int f(int a, int b, int c) { … }

add argument to all calls to f

Bob: add call f(x,y)

Merged program- Has no conflicts- But will not even compile

Don’t Forget

• Merging is syntactic• Semantic errors may not create conflicts

– But the code is still wrong– You are lucky if the code doesn’t compile

• Worse if it does . . .

– Rare in practice, if you maintain good team communication

• Make it a habit to check status of files before doing a commit, to avoid unnecessary pain of merge clean up.

Subversion Details

Subversion

• Developed in 2000 and 2001 (by CollabNet, Inc.) to replace CVS and its shortcomings– Subversion is free– Subversion is open-source– Subversion operates across a network– Subversion handles any types of files,

documents, or directories– Subversion requires administrative

support

http://svnbook.red-bean.com/

• manages changes on a per file basis• log messages for each change• remote repository access• tagging a set of files for later access • invoked as svn from the command line

Subversion’s Storage Repository

• Subversion provides a centralized storage repository– Storage repository acts as a fileserver– Clients connect, then

read from or write to files– Clients can also view logs

of changes made to filesor directories

– All changes are logged,storing date, time, user responsible, user-specified notes

Basic Tasks

• administrative setup

• getting a working copy

• committing and understanding changes

• adding a file

• removing a file

• updating to the latest code

Getting a Working Copy

• get a new copy of the repository with:

svn checkout <modulename>

where modulename is the name of the project you want to checkout

svn checkout https://cengsvn.anadolu.edu.tr/svn/bim313/public/

Working Copies

• A Subversion working copy is an ordinary directory containing checked-out copies of files/directories in the repository

• Your working copy is your own private work area:

Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so

Making Changes

• you make changes to your local copy and then commit them to the repository

• it is good form to make sure your changes compile before you commit

Reviewing & Committing Changes

• After appropriate changes, deletions, and additions have been made, you may commit your changes– SVN records

your changesand associates themwith a new revision number

– Update the repositorywith all of your changesby performing a commitfrom the top-level folder

svn commit

Importance of Revisions

We can refer to past versions of files & dir’s:

• By revision number: svn diff –r 3:4• By keyword: svn log -–revision

HEAD• By dates: svn checkout –r {2002-

06-22}

Revisions are our time machine!

Revision Keywords

1. HEAD: Latest revision in repository

2. BASE: The “pristine” copy of the working copy (i.e. when checkout was done)

3. COMMITTED: The last revision in which item actually changed (or at BASE)

4. PREV: The revision just before last revision in which an item changed (COMMITTED-1)

Viewing Changes

• to view the difference between your current file and the latest file in the repository:

svn diff file• for differences between your file and a some previous

version X.Y:svn diff -r X.Y file• to show record of all changes (not the actual changes)

done in repository:svn log file• to compare status (up to date, out of date, etc) of

working copy to latest revision in repositorysvn status

Committing Changes

• Describe your changesfor the revision log – Commit from

the top-level folder

– Every change that youcommit goes downin history....

svn commit -m “Initial addition “

Updating to the Latest Code

• to update your working copy to the latest code in the repository:

• useful flags:– A reset any sticky tags/date/kopts– P prune empty directories– d build directories, like checkout does

svn update

Update Codes

• M file modified in your local copy• U file brought up to date with repository• ? file is in your local copy but not in the

repository• C a conflict was detected between your local

copy and the repository copy• A file is scheduled to be added to the

repository• R file is scheduled to be removed from the

repository

Conflicts on Update

• your partners may have made changes that conflict with your changes– known as a conflict– C code on update

• edit the file to resolve the conflict

• commit only after you have resolved the conflict

Reverting Changes

• to revert a file in your local copy (based on version X.Y) to version W.Z in the repository:

svn update -j X.Y -j W.Z file• svn revert

Undo any changes done to working copy (i.e. revert back to latest revision in repository)

• order matters• directory and file renames cannot be reverted

Typical Workflows

• Update your working copy (i.e. your local repository):– svn update

• Change your working copy:– svn add– svn delete– svn copy– svn move– svn mkdir

Typical Workflows

• Review your changes:– svn status– svn diff– svn revert (undo)

• Resolve conflicts by merging:– svn update– svn resolved

• Commit your changes:– svn commit

Common Problems

• forgot to tag the repository– checkout by date– remember to unset the sticky tagssvn checkout -D “YYYY-MM-DD HH:MM:SS”

• partners commit broken code– don’t let them– back out changes

Stuff We Didn’t Cover

• svn can keep track of multiple lines of development with the branches– there are subtle issues merging across

branches– see the documentation for the whole story

• support for exclusive checkouts of files

• take arbitrary action on file commit

Common SVN Commands (1/2)

svn [svn-options] command [cmd-options] [files]

• add: svn add foo

• cat: svn cat svn://fooExamine/Obtain an earlier version of a file or directory

• checkout (co): svn co svn://host.com/dir/proj

• commit (ci): svn commit -m “log message”

• copy (cp): svn cp svn://foo svn://bar

• delete (rm): svn rm svn://foo

• diff: svn diff -r123 foo

• import: svn import svn://foo -m “import msg”

Common SVN Commands (2/2)

• info: svn info

• list (ls): svn ls svn://fooShow a list of all files and directories in repository

• log: svn log fooShow record of all changes done in repository

• mkdir: svn mkdir foo

• move (mv): svn mv svn://foo svn://bar

• resolved: svn resolved fooUsed to declare all conflicts have been resolved

• status: svn status -u

• update (up): svn up

Additional Recommendations

• Usage recommendations:– Avoid storing binary files or JARs

• Binary files use a lot of repository space

– Avoid storing IDE-specific files• e.g. do not store Eclipse or IntelliJ IDEA

workspace or project files

– Commit changes at meaningful checkpoints• Frequently enough for others to

share in development• Infrequently enough so as

not to create too many revisions

SVN online

• Official SVN site: http://subversion.tigris.org/

• SVN tutorial: http://svnbook.red-bean.com/

• SVN on Wikipedia: http://en.wikipedia.org/wiki/Subversion_(software)

References

• http://www.stat.washington.edu/albert/presentations/2005-11-02-subversion/subversion.ppt

• http://cc.ee.ntu.edu.tw/~tianliyu/workshop/svn-tut.ppt

• http://academic2.strose.edu/math_and_science/goldschd/docs/2008-02-29%20Subversion.ppt