240 likes | 391 Views
Version Control using Subversion. Albert Young-Sun Kim November 2 nd , 2005 Available at http://www.stat.washington.edu/albert/presentations/2005-11-02 -s ubversion/. Why use version control?. Manage file sharing (Specifically: Prevent people from erasing each other’s modifications)
E N D
Version Control using Subversion Albert Young-Sun Kim November 2nd, 2005 Available at http://www.stat.washington.edu/albert/presentations/2005-11-02-subversion/
Why use version control? • Manage file sharing(Specifically: Prevent people from erasing each other’s modifications) • Keep past versions of files/directories • Other benefits not relevant to us
1. At the Heart of Subversion:The Repository • Typical Client/Server System • The Repository is a kind of file server. However, Subversion remembers every change ever written to it!
The Problem of File Sharing • We want to avoid the following scenario: Overwriting each other’s modifications
One Solution: Lock-Modify-Unlock • Only one person may modify a file at any time. • While this occurs, others can read the file, but not write to it
Problems with Lock-Modify-Unlock • Can cause unnecessary delays (Say Harry forgets to unlock his file before going on vacation) • Even more unfortunate if Harry and Sally’s changes don’t overlap
Better Solution: Copy-Modify-Merge Subversion does this!
Notes on Merge • When changes don’t overlap, merge is automatic • When they do overlap, this is called a conflict. There are methods to efficiently handle this. • May seem chaotic, but conflicts are rare and the time it takes to resolve conflicts is far less than the time lost by a locking system. (Assuming good communication between users, of course!)
Access Repository can be accessed: • Via file:// serverEasiest for us (since we’re all on Madrid) • Via http:// serverRequires in-depth knowledge of Apache • Via svn:// serverEasiest across network access • Via svn+ssh://Same as svn://, but more secure
2. Working Copies • A Subversion working copy is an ordinary directory containingchecked-outcopies of files/directoriesin 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
3. Revisions • Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision
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 • HEAD: Latest revision in repository • BASE: The “pristine” copy of the working copy (i.e. when checkout was done) • COMMITTED: The last revision in which item actually changed (or at BASE) • PREV: The revision just before last revision in which an item changed (COMMITTED-1)
4. Getting Started • Create repository • Import initial files and directories to repository • Initial checkout in order to obtain a working copy • Basic Work Cycle
5. Basic Work Cycle: (Also most common commands) • Update your working copy • svn update • Make changes • svn add • svn delete • svn copy • svn move • Examine your changes • svn status • svn diff • svn revert
5. Basic Work Cycle • Merge other’s changes • svn update • svn resolved • Commit your changes • svn commit • (Optional) Examining History • svn log • svn list • svn cat
a) Update your working copy • svn updateBrings your working copy in sync with the latest revision in the repository
b) Make changes • svn add • svn delete • svn copy • svn move All these commands are on used on files and directories in the repository. Use these instead of standard UNIX commands mv, rm, etc…
c) Examine your changes • svn status (used the most)Compares status (up to date, out of date, etc) of working copy to latest revision in repository • svn diffCompares the difference between working copy and latest revision in repository • svn revertUndo any changes done to working copy (i.e. revert back to latest revision in repository)
d) Merge other’s changes • svn updateSeen in a) • svn resolvedUsed to declare all conflicts have been resolved
e) Commit your changes • svn commitCommit the working copy to the repository. (i.e. check-in a new revision in repository)
f) (Optional) Examining History • svn logShow record of all changes (not the actual changes) done in repository • svn listShow a list of all files and directories in repository • svn catExamine/Obtain an earlier version of a file or directory
More Detailed Explanations More detailed explanations of the previous commands of the Basic Work Cycle can be found in Chapter 3 of “The Subversion Book” found online. Particularly the notes on conflict resolution. Pages 19-41 of the pdf version: http://svnbook.red-bean.com/en/1.1/svn-book.pdf
6. References • Collins-Sussman, B., Fitzpatrick, B.W., Pilato, C.M. (2005). Version Control with Subversion (aka The Subversion Book) http://svnbook.red-bean.com/ Notes: Only the first 3 chapters are relevant to us. Chapter 1 includes a quick start guide, Chapter 2 discusses the philosophy of Subversion and Chapter 3 is a guided tour of the basic commands • Mason, M. (2005). Pragmatic Version Control Using Subversion. Pragmatic Bookshelf. Notes: This book explains Subversion/Version Control from a programmers’ point of view. Available at UW libraries.