Post on 31-Jan-2018
transcript
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