1. Version Control using Subversion Albert Young-Sun Kim November 2 nd, 2005 Available at http://www.stat.washington.edu/albert/pres entations/2005-11-02-subversion/ http://www.stat.washington.edu/albert/pres entations/2005-11-02-subversion/

2. 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

3. 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!

4. The Problem of File Sharing We want to avoid the following scenario: Overwriting each other’s modifications

5. 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

6. 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

7. Better Solution: Copy-Modify-Merge Subversion does this!

8. 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!)

9. Access Repository can be accessed: 1.Via file:// server Easiest for us (since we’re all on Madrid) 2.Via http:// server Requires in-depth knowledge of Apache 3.Via svn:// server Easiest across network access 4.Via svn+ssh:// Same as svn://, but more secure

10. 2. 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

11. 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

12. 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!

13. 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 )

14. 4. Getting Started 1.Create repository 2.Import initial files and directories to repository 3.Initial checkout in order to obtain a working copy 4.Basic Work Cycle

15. 5. Basic Work Cycle: (Also most common commands) a)Update your working copy svn update b)Make changes svn add svn delete svn copy svn move c)Examine your changes svn status svn diff svn revert

16. 5. Basic Work Cycle d)Merge other’s changes svn update svn resolved e)Commit your changes svn commit f)(Optional) Examining History svn log svn list svn cat

17. a) Update your working copy svn update Brings your working copy in sync with the latest revision in the repository

18. 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…

19. 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 diff Compares the difference between working copy and latest revision in repository svn revert Undo any changes done to working copy (i.e. revert back to latest revision in repository)

20. d) Merge other’s changes svn update Seen in a) svn resolved Used to declare all conflicts have been resolved

21. e) Commit your changes svn commit Commit the working copy to the repository. (i.e. check-in a new revision in repository)

22. f) (Optional) Examining History svn log Show record of all changes (not the actual changes) done in repository svn list Show a list of all files and directories in repository svn cat Examine/Obtain an earlier version of a file or directory

23. 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 http://svnbook.red-bean.com/en/1.1/svn- book.pdf

24. 6. References 1.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 2.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.