SOURCE CODE CONTROL SYSTEMS OVERVIEW Lab 3 EECS 448 Dr Fengjun Li and Meenakshi Mishra

Overview • Source Code: A solution to a problem • Source code can be highly complex

•  Many lines of code •  Many different modules

• Versions of source code •  Updating software •  Debugging during development •  Versions of software created

• Version of product is defined by the version of its source files

Overview • Source code control systems: Tools to keep record of

versions and updates my multiple people • Keeping versions can be annoying • Some developers tackled this problem and created several

tools for version control • Various version control systems

•  SCCS -> RCS -> CVS -> SVN -> GIT, Bazaar etc •  Microsoft, At&t, others create local tools

Basic Concepts •  Fundamental distinction between repository and working

copy • Repository

•  Place where tools maintain information about all files in all versions of software

• Working copy •  Copy of specific version of source files in specific directory location •  You and others can check out multiple working copies at same time

in arbitrary place •  Always work in the working copy •  Always issue commands in the working copy

Basic Concepts • Original methods focused on single files • Each file could only have one series of version

•  1.1 -> 1.2 -> 1.3 -> 1.4 ...

• Main line of development is called trunk • Now, branches can be created from any version • Branches are created for independent development or

maintenance changes • Branches can be merged back to original work

Basic Concepts • Basic SCCS operations

•  Checkout •  Get a working copy from the repository

•  Check In •  Create a new version of the files changed in working copy during

development •  Status

•  Check the state of files in working copy •  Others

•  Other tools, depending on the specific needs, also include tools for file manipulation

Brief History: SCCS • Early revision control system • Developed in Bell Labs in 1972 by Marc Rochkind, later

written by him in C for Unix • Kept track of version of each source file

•  Later, S-List tools were developed by Bell Labs to track sets of source files

• No development in SCCS since 1999 • Generally considered obsolete

Brief History: RCS • Revision Control System • Released in 1982 by Walter F. Tichy at Purdue University • Evolved as an alternative to SCCS • Still operated on single file, provided branching for

individual files •  Improved some features of SCCS

•  Reverse diffs vs forward diffs for storing files •  Tagging of current set of file versions to permit checking out a

version of the product

Brief History: CVS • Concurrent Versions System • Developed by Dick Grune as a series of shell scripts in July

1986 • Remote repository made easier • Explicit support for individual workstations vs many

developers logging in a common set of server machines • Better support for branching • Automated merge of branch development • Highly popular

Brief History: SVN • Subversion created to develop a better CVS • CVS Limitations

•  Still tracked versions of individual files as primary mechanism, supplemented by tags

•  Moving and renaming directories painful •  Crude support for binary files

• Database approach to repository management •  Version of whole repository is tracked, not of individual files •  File and directory tree copying adopted as primary mechanism

Brief History: SVN • Adopted URL as repository access method

•  SVN a little more difficult to set up and support than CVS •  Uniform access designations are a help •  URLs not needed in working copies

• Better Support than CVS •  File and directory movement and renaming •  Binary files •  Tags and branches

•  Tags and branches are specific uses of copies

Brief History: Distribution • SVN used the centralized repository model exclusively •  Intermittent connectivity and geographically distributed

development groups became more and more common • Bitkeeper: an early commercial effort popular with Linus,

and thus for Linux development • Mercurial: Written in python, making it easier to incorporate

Python based GUI • Darcs: Written in Haskell, tracks versions as series of

patches • Bazaar: Supports both centralized and distributed models

Brief History: Git •  Implemented in C • Distributed revision control and source code management

system • Every Git working directory is repository •  Linux kernel maintenance passed around changes as

patches and archived files •  In 2002 Linux started using DVCS, BitKeeper • Relationship between Linux and BitKeeper broke down •  Linux set forth to build a similar DVCS improving on speed,

design, stronger support for non-linear development, ability to handle larger projects and fully distributed

• Birth of Git in 2005

SVN: Overview •  First step is to create a repository • EECS has support for all accounts to have its own

repository •  http://wiki.eecs.ku.edu/subversion •  To create a repository

•  cd •  svnadmin create Repository •  chmod -R 770 Repository

SVN: Overview •  First check out a working copy of the empty repository

•  svn co https://svn.eecs.ku.edu/<your-login> my_svn • A working copy of the repository named “my_svn” • Many “.svn” directories in the working copy

•  Contain information like last revision when working copy was issued helping in updating the files

SVN check out • Check out

•  Fetches a working copy of the designated source if it is not already present

•  svn co <url> <local directory> • Can check out any URL referring to a part of the repository

into a directory of any name •  If local directory is not specified, the same name as the last

component of the URL is used •  Last output line notes revision number of the copy

•  Revision number tells the state of the whole repository and increases monotonically

SVN Status • Can edit any file checked out in the working copy • Can check the status of the files with respect to repository •  svn status •  svn status <file or dir> • Abbreviations used

•  A: file added but not committed •  M: file modified •  D: file deleted •  ?: file not under version control •  C: Conflict needed to be resolved by hand •  !: missing expected file

SVN Commit • After you have made a set of changes in your working

directory and you want to preserve them, you need to commit the changes

•  svn commit -m “Comment” <dir or file-list> •  This will commit all the changes to the files listed and all

the changes anywhere in the directories listed •  -m option allows you to add a message that will summarize

the change you made in the working directory •  If you omit this, svn will create an editor session for each file being

changed in which you can compose a summary of changes

SVN add • Adds files and directory • Adding is still done in the working directory. •  svn add <file or dir> • You will need to commit the changes before the repository

contains the new files

SVN Copy, Move, Delete, Rename •  These commands operate in the obvious ways •  svn delete fred •  svn move foo bar •  svn rename fred sue •  svn copy john mary •  If you execute some of these commands, always commit

before continuing your work •  Not required but good in practice

SVN Update • Consider the case of multiple users • You check out a working copy and other user makes

changes in your repository • Update command is used to bring version of local working

copy up to that of repository • Make it habit to keep updating frequently

•  If conflicts occur in advanced stages, they might be harder to solve

SVN Update • Update at a given directory level and below • Will simply announce the revision of the working copy if the

local copy is up to date •  svn update •  It will list files with different state from new revision

preceded by a letter symbolizing the difference •  U: updated from repository -somebody changed it •  A: added to working copy •  D: Deleted from working copy •  R: replaced in your working copy •  G: successful automatic merge •  C: conflict that must be resolved by hand •  !: missing expected file

SVN diff • Run the diff command on two specified version of files or

directories that may or may not be explicitly specified •  svn diff Fred

•  Diffs between current working copy and most recent version in repository

•  svn diff -r x:y Fred •  Diffs Fred at revision x against revision y

•  svn diff <dir-name> •  Recursively diffs everything in the directory

SVN Revert • Reverts the current working copy with respect to specific

revision in the repository •  svn revert Fred •  svn revert -r x Fred •  svn revert

•  Careful: This will revert everything in current directory to the HEAD revision

Branches • Branching is more of an user convention • Sometimes you need to take your project away from main

league and work on longer parts •  Typical structure in svn: trunk, branch, tags •  svn copy whatever needs to be branched from trunk

directory to a branch directory •  Branch directories should include components of who created the

branch and of what

SVN merge and resolve • Merge changes made to one file or directory along a

specific branch into corresponding file or directory along other branch or trunk

• SVN will attempt to auto-merge changes to the same file • Overlapping changes conflict, manual merge required • After manual merge •  svn resolve Fred

Tags •  Tags also exist by convention • Store the version you want to save separately •  Just copy the version of your work in trunk you want to

save in the Tag folder with appropriate name • A tag is essentially an association of a label meaningful to

humans with a particular portion of the repository

SVN log • A log is the revision of the entire repository or any specified

portion •  svn log <file or dir>

• Options control the type, level of detail and the extent of the revision history provided •  svn log --verbose : expands data for each revision •  svn log –r x:y : history from revision x to y •  svn log --xml : output history in xml format •  svn log --stop-on-copy

•  Goes back only as far as first copy which created this component •  Excellent for finding root of branches

Basic Work Cycle • Update your work copy svn update

• Make changes to structure svn add svn delete svn copy svn move

• Examine your changes or undo them svn status svn diff svn revert

Assignment • Set up your own repository

•  svnadmin create Repository •  chmod –R 770 Repository •  Go inside the Repository •  Create a file named “authorized_users” •  Notice no extension in the file •  In this file, write

[<your eecs id>:/] <your eecs id> = rw

Assignment • Check if the repository is set up fine

•  Goto your browser window and type the following URL •  You should see empty pane with your username and revision

number possibly ‘0’ • Navigate to where you want your working copy •  Try: svn help •  Try: svn help checkout • Check out working copy of your repository

•  svn co https://svn.eecs.ku.edu/<eecs_login> <working_copy>

Assignment • Move inside your working copy •  Type: ls –a • Which files do you see?

•  .svn file contains information svn uses to maintain version control. Modification or deletion of this file can invalidate your entire repository

Assignment • Create a directory “lab” for today’s work only • Create lab/tag, lab/trunk, lab/branch • Add the directory lab svn add lab

• Commit your changes svn ci –m “message”

Assignment • Copy your calculator assignment in your lab directory in the

trunk folder • Add the file and commit change • Change something in the file and commit change • Copy a branch of this code in branches directory svn copy <source-url> <desired branch url>

Assignment • Modify the branch and check in the change

•  The file in trunk should remain unchanged • Merge your file back to the trunk

•  Change to the root of your trunk directory •  svn merge <url-of-branch> •  Now the change should also be made to trunk

Giving authorization to other people • Open the file “authorized_users” in Repository and add the

following lines [<your_EECS_login>:/project/publish] <User1_EECS_ID> = rw <User2_EECS_ID> = r

Centralized version control

Distributed version control

Git • Stores snapshots not differences • Nearly every operation is local

•  Allows you to work anywhere •  Can access any version of your files without being on the network

• Everything in Git has checksum •  Not possible to make changes without git not knowing about it

States of Git

Cloning existing repository •  git clone [url]

•  Notice command is clone and not checkout •  You will receive nearly all the data server has •  Pulls down all the information from the repository

File status Life Cycle

Check status of files •  git status

•  Untracked files •  List of new files not yet formally added

•  Changes to be committed •  Staged files waiting to be committed

•  Changes not staged for commit •  Modified files not yet staged

Git: add • Begin tracking new file or to stage modified files

•  git add file •  The new file becomes staged •  To add it to historical snapshot, need to commit •  Suppose you stage a file, then modify it and then commit it, then

run git status •  You will see same file in staged and unstaged list •  The file in staged is prior to your latest changes •  If you commit, your latest changes will not be committed

Git: diff •  To see what you have changed but not staged

•  git diff •  To see what you have staged that will go in the next

commit •  git diff --cached (git diff --staged)

Git: commit • Commit your changes •  Launches editor with message of commit

•  Default commit message is git status text •  You can pass -v option to pass git diff text as message •  You can also pass -m option with inline message •  git commit –m “New changes made”

Staging area • Useful for crafting commits as you want • You can also ignore the staging area without using git add

command •  git commit -a -m “commiting all files”

Removing, moving, renaming •  To remove a file from git, you need to remove it from

tracked files and then commit •  git rm filename •  If you modified the file, you must force its removal with -f option •  If you just want to remove a file from the staging area, but keep it in

your working tree then •  git rm --cached filename

•  To move a file •  git mv file1 file2 •  Also used for renaming

Changing your last commit •  git commit --amend • Suppose you forgot to add some file in your last commit,

then just add that file and run the amend option git commit -m “First commit” git add additional_file git commit --amend

Only initial commit is created

Moving files backward one stage • Unstaging staged file

•  Command showed in git status •  git reset HEAD filename

• Unmodifying modified file •  git checkout -- filename •  Command is shown in git status as well

Remote repositories •  git remote • You should see your public repository called origin •  If you have added others, you can see them too •  To add remote directories

•  git remote add [name] http://people.eecs.ku.edu/~[username]/git/[project_name].git

•  To pull from remote directories •  git pull [name] master

•  To push to your remote repository •  git push origin master •  You can only push to server you have write access to, from which

you had cloned and nobody else has made changes to it

Remote Repositories • Renaming remote

•  git remote rename Fred Susie • Removing remote

•  git remote rm Fred

Tagging •  List of tags

•  git tag •  Create a tag

•  Annotated tag •  git tag -a v3.2.4 -m “New version”

•  Lightweight tag •  Just stores the commit checksum

•  git tag v3.2.4 •  See tag data

•  git show •  Tagging later

•  git log --pretty=oneline •  git tag -a v1.2 -m “some version” [part of the checksum displayed]

•  Sharing tags •  git push does not transfer tag •  git push origin --tags

Git Branching • Git stores data as a series of snapshots • Branch is a lightweight movable pointer to one of the

commits • Default branch name in git is master •  Initially, master points to the last commit •  If you create another branch, means you are creating

another pointer •  git branch testing •  Special pointer “HEAD” tells git what branch you’re at

Git branching

git checkout testing

•  git checkout is different from SVN checkout •  What happens if we do commit now?

Git branching • What happens if we move the head to master and commit

a change •  git checkout master •  git commit -a -m “some change”

Basic Merging • Suppose your testing branch work is complete • Now you need to merge to master •  git checkout master •  git merge testing

Set up your own git system • wiki.eecs.ku.edu/git •  git config --global user.name “Your name” •  git config --global user.email “you@ku.edu” •  git config --global core.askpass “”

Create Private Repository •  git init ~/my_git • You can also make an existing directory your private

repository •  git init ~/existing_directory_path

Create public Repository • mkdir ~/public_html/git •  cd ~/my_git •  git clone --bare ./ ~/public_html/git/[project_name].git •  git remote add origin ~/public_html/git/project_name.git •  cd ~/public_html/git/[project_name].git •  cp hooks/post-update.sample hooks/post-update •  git update-server-info

Assignment • Goto your private repository, my_git • Create a folder Lab4 • Create a file named test.txt in Lab4 and write something in

it • Check the status (git status)

•  You should see the file as new file •  You should also see the option to add it

• Create another file test1.txt • Stage the file test.txt (git add test.txt) • Check the status

•  You should see one file as staged and other as new file •  You should see commands to unstage and commit the staged file

as well

Assignment • Add all the files and commit (git commit -m “message”) • Push the contents to public repository (git push origin

master) • Make some change to the file • Add the file, commit • Check the log (git log)

Authorizing access to other users • Goto base of public repository • Create a file named “.htaccess”

# ~/public_html/git/[project_name].git/.htaccess file contents AuthName “Project Name” AuthType basic AuthBasicProvider ldap Require user [userID1] [userID2].. Save this .htaccess file and exit. Run the command to clean up public repository. git gc

Create your Project Repository • Goto git.eecs.ku.edu • Sign in using your eecs username and password • Create a new project called EECS448_Project •  Follow the instructions provided to add this new public

repository to your workspace •  The instructions are very similar to what you executed to

join your public and private repositories in your eecs profiles

• Notice you cannot push anything to your repository

Create your Project Repository •  In your terminal, type •  ssh-keygen -t rsa -C ”email” •  Just press enter for requests for file name to store and

passphrase •  Type: cat ~/.ssh/id_rsa.pub • Copy the key shown •  In your git webpage account, there should be a link to add

ssh key on the top of your page • Paste this key and submit • You can now use your repository

Add users to your repository • At the top right corner of git webpage, there is a small

blank profile picture, click this • Click on your project •  In the bar that reads SSH, there is a drop down menu • Select project member from drop down menu • Add project members for the group when needed