version control *slides are modified from prof. necula from cs169
TRANSCRIPT
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