Version Control
Why Version Control?
Problem #1: Collaboration - what if two or more people want to edit the same file at the same time?
Option 1: make them take turns
- But then only one person can be working at any time
- And how to you enforce this?
Option 2: patch up differences afterwards
- Requires a lot of re-working
- Stuff always gets lost
Solution: Version Control This keeps the master copy of the file in a central repository, an each author edits a working copy. When they're ready to share their changes, they commit them to the repository. Other people can then do an update to get those changes.
This is also a good way for one person to manage files on multiple machines. Keep one working copy on your personal laptop, one on the lab machine, and one on the departmental server. No more mailing yourself files, or carrying around a USB drive (and forgetting to copy things onto it).
Problem #2: Undoing Changes
Often want to undo changes to a file, or keep track of who changed what and when.
Solution: Version Control (Again)
The version control system keeps old revisions of files, records who made the change, and when. Authors can then roll back to a particular revision or date.
Which Version Control System?
If you have a large group, or a budget, Perforce is excellent. On the other hand, CVS and Subversion are open source, reliable and well documented. CVS has been around since the 1980s, and has its flaws, most of which are fixed by Subversion, a replacement which feels almost the same.
Basic Use
Suppose Ron and Hermione each have a working copy of the solarsystem project repository, and Ron wants to add some information about Jupiter's moons. Ron runs svn update to synchronize his working copy with the repository. Then he goes into the jupiter directory and creates moons.txt:
Name Orbital Radius Orbital Period Mass Radius Io 421.6 1.769138 893.2 1821.6 Europa 670.9 3.551181 480.0 1560.8 Ganymede 1070.4 7.154553 1481.9 2631.2 Callisto 1882.7 16.689018 1075.9 2410.3Ron then runs svn add moons.txt to bring it to Subversion 's notice, and runs svn commit to save his changes in the repository (the repository is now at revision 121)
That afternoon, Hermione runs svn update on her working copy, and subversion sends her Ron's changes.
Resolving Conflicts
Option 1: only allow one person to have a writeable copy at any time
- This is called pessimistic concurrency (used in Microsoft Visual SourceSafe)
Option 2: let people edit, and resolve conflicts afterward by merging files
- Called optimistic concurrency
- “It's easier to get forgiveness than permission”
- Most modern systems (including Subversion) do this
Example of Resolving
Ron and Hermione are both synchronized with version 151 of the repository, and Ron edits moon.txt then commits his changes to create version 152. Simultaneously, Hermione edits her copy of moons.txt. When she tries to commit, Subversion tells her there's a conflict.
Subversion puts both Hermione and Ron's changes in moons.txt, but adds conflict markers to show where they overlapped:
Name Orbital Radius Orbital Period Mass Radius Io 421.6 1.769138 893.2 1821.6 Europa 670.9 3.551181 480.0 1560.8 <<<<<<< .mine Amalthea 181.4 0.498179 0.075 131 Himalia 11460 250.5662 0.095 85 ======= Amalthea 181.4 0.498179 0.075 131.5 Elara 11740 259.6528 0.008 40 >>>>>>> .r152 Subversion also creates:
- moons.txt.mine - contains Hermione's changes
- moons.txt.151 - the file before either set of changes
- moons.txt.152 - the most recent version of the file in the repository
At this point, Hermione can:
- Run svn revert moons.txt to throw away her changes
- Copy one of the three temporary files on top of moons.txt
- Edit moons.txt to remove the conflict markers
- Once she's done, she runs:
- svn resolved moons.txt to let Subversion know she's done
- svn commit to commit her changes (creating version 153 of the repository)
Reverting
After doing some more work, Ron decides he's on the wrong path; svn diff shows him which files he has changed, and what those changes are. He hasn't committed anything yet, so he uses svn revert to discard his work (i.e., throw away any differences between his working copy and the master as it was when he started). This synchronizes with where he was before, not including any changes other people have made since then.
Creating and Checking Out
To create a repository, you must decide where to put it (e.g., /svn/rotor). Go into the containing directory - cd /svn, then run svnadmin create rotor.
You can then check out a working copy directly through the file system:
svn checkout file:///svn/rotor
Or through a web server:
svn checkout http://www.hogwarts.edu/svn/rotor
(Note: this requires your system administrator to configure the web server properly)
You only need to use svn checkout once, to initialize your working copy. After that, use svn update in that directory. If you only want part of the repository, use
svn co http://www.hogwarts.edu/svn/rotor/engine/dynamics
Subversion Command Reference
Name Purpose/Example
svn add Add files and/or directories to version control.
svn add newfile.c newdir
svn checkout Get a fresh working copy of a repository.
svn checkout https://your.host.name/rotor/repo rotorproject
svn commit Send changes from working copy to repository (inverse of update ).
svn commit -m "Comment on the changes"
svn delete Delete files and/or directories from version control.
svn delete oldfile.c
svn help Get help (in general, or for a particular command).
svn help update
svn log Show history of recent changes.
svn log --verbose *.c
svn merge Merge two different versions of a file into one.
svn merge -r 18:16 spin.c
svn mkdir Create a new directory and put it under version control.
svn mkdir newmodule
svn rename Rename a file or directory, keeping track of history.
svn rename temp.txt release_notes.txt
svn revert Undo changes to working copy (i.e., resynchronize with repository).
svn revert spin.h
svn status Show the status of files and directories in the working copy.
svn status
svn update Bring changes from repository into working copy (inverse of commit ).
svn update
Subversion Output
svn status compares your working copy with the repository, and prints one line for each file that's worth talking about
$ svn status
M jupiter/moons.txt
C readme.txt
This means jupiter/moons.txt has been modified, and readme.txt has conflicts.
svn update prints one line for each file or directory it does something to
$ svn update
A saturn/moons.txt
U mars/mars.txt
Meaning saturn/moons.txt has been added, and mars/mars.txt has been updated (i.e., someone else modified it).
Page Author
- Avatar
- Name
- viverson
From Here You Can…
Information
- 198 Views
- 0 Comments
© 2008 Vicki Iverson, All Rights Reserved.
