Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Subversion and TortoiseSVN – a Basic Primer<br />Blake Medulan<br />2008<br />
  2. 2. What is it?<br />Subversion (abbreviated SVN) is an open source version control system that facilitates source code development by multiple software developers.<br /><ul><li>Web Access
  3. 3. SSH
  4. 4. Windows Shell</li></li></ul><li>Why we use it<br />SVN allows us to easily <br />maintain backups of source code<br />automate deployment<br />keep copies of every single version of the code<br />prevents developers from overwriting each other's work.<br />roll back to previous versions of code<br />
  5. 5. Vocabulary<br />SVN : abbreviation for subversion<br />Head Revision: The latest (or “youngest”) revision in the repository.<br />Conflict: Two competing versions of the same file<br />Working Folder: Folder (local or server) that you check out the code to in order to edit<br />Commit : Publish new files to repository<br />Branch: a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time.<br />
  6. 6. Vocabulary<br />Base : The revision number of an item in a working copy. If the item has been locally modified, this refers to the way the item appears without those local modifications.<br />Prev: The revision immediately before the last revision in which an item changed. Technically, this boils down to COMMITTED#1.<br />WebDAV: Distributed Authoring and Versioning.” RFC 2518<br />
  7. 7. TortoiseSVN<br />TortoiseSVN is a Windows shell extension that allows you to access SVN repositories within Windows Explorer. <br />Basically, any folder on your hard drive (or remote server) can be turned into an SVN folder and used to store a revision of an SVN repository<br />
  8. 8. TortoiseSVN<br /><ul><li>Once a directory is identified as version controlled, the following icons are used</li></li></ul><li>Checkouts and Commits<br />To work with SVN version-controlled source code, you must first 'check out' the current version of the code (or possibly an older version, if necessary)<br />Updated code can then be 'committed' back to the SVN repository as a new version of the source code, and <br />Subsequent attempts to check out the latest version of the code will acquire this newer, updated version.<br />
  9. 9. The “Checkout” operation<br />STEPS<br />1. Create a working folder locally<br />2. Right click on folder select SVN Checkout<br />3. Enter repository location<br />(<br />(http://subversion.webfeat.mci/project_xxx)<br />4. Select working folder<br />
  10. 10. The “Checkout” operation<br />STEPS<br />5. Enter your username and password<br />6. Checkout process begins<br />7. Working folder now contains latest version<br />The green check means that the folder contains SVN files and is version controlled.<br />
  11. 11. The “Commit” operation<br />STEPS<br />1. Right-clicking on the file, sub-folder, or repository folder (whichever will cover the entire set of files/folders you have changed), and select SVN Commit.... <br /><ul><li>2. Enter log message</li></ul>Only use accurate, descriptive comments so others can understand how the new version of code you are creating differs from the previous version!<br />
  12. 12. Rename Files and Folders<br />1. Checkout the file or folder to your machine<br />2. Right-click on the file or folder, and select the menu option SVN Rename<br />3. Type in the new name, and the icon for the file or folder will change to;<br />4. Run a Commit and the repository will be updated with the new name<br />
  13. 13. Delete Files and Folders<br />1. Checkout the file or folder to your machine<br />2. Right-click on the file, and select the Delete... option from the TortoiseSVN menu:<br />
  14. 14. Adding Files and Folders<br />1. Checkout the latest version<br />2. Move the new file(s) and folder(s) to the location you want them in the repository<br />3. Right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN Add.<br />4. To make the change stick, run a Commit and make sure the check boxes are checked for adding the items you want to add<br />
  15. 15. Updates<br />1. Update your local snapshot of the repository to the latest version available by running an Update Operation.<br />2. Right-click on a folder containing versioned files and folders in it, and select the SVN Update... menu option.<br />NOTE:<br />Only the files already checked out will be updated (or deleted, if they were deleted in the repository since you last updated)<br />Only the files already on your hard drive will be touched, and they can only be deleted or overwritten with the latest version of the file.<br />
  16. 16. Conflicts – the scenario<br />In the following example, we will be committing a change to the repository. Note: please don't actually make a commit to the repository for this tutorial - just read along! (We don't want the iris4 repo to get messed up with a bunch of 'SVN practice' commits.) <br />If you have modified any of the files you have checked out, added new files to the folder (or a sub-folder) where you have versioned files, or if you have deleted versioned files, you will have to commit these changes to the SVN repository to try and make them stick. I say try here because it is possible that the commit operation will fail if your changes conflict with someone else's changes<br />
  17. 17. Conflicts<br />When you try to commit your file you get the following message<br />You then run an Update operation, and you will see the following:<br />
  18. 18. Conflicts<br />After you click OK, the folder containing main.cpp will now have several new, non-versioned files in it:<br />3<br />1<br />4<br />2<br />
  19. 19. Conflicts<br />main.cpp.mine<br /> This is what main.cpp v31 looked like after you changed it (no conflict markers).<br />main.cpp.r31<br />This is what version 31 of main.cpp looked like (the file you checkout and then modified).<br />main.cpp.r32<br />This is what the current version of main.cpp looks like (on the server).<br /> main.cpp<br />During the Update operation, conflict markers were inserted into this file.<br />
  20. 20. Conflicts<br />You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:<br />
  21. 21. Conflicts<br />You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:<br />
  22. 22. Branching<br />The Never-Branch system<br />(Often used by nascent projects that don't yet have runnable code.)<br />Users commit their day-to-day work on /trunk.<br />Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.<br />Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge.<br />Cons: Chaotic development, code could be unstable at any time.<br />
  23. 23. Branching<br />The Always-Branch system<br />(Often used by projects that favor heavy management and supervision.)<br />Each user creates/works on a private branch for every coding task.<br />When coding is complete, someone (original coder, peer, or manager) reviews all private branch changes and merges them to /trunk.<br />Pros: /trunk is guaranteed to be extremely stable at all times.<br />Cons: Coders are artificially isolated from each other, possibly creating more merge conflicts than necessary. Requires users to do lots of extra merging.<br />Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.<br />
  24. 24. Branching<br />The Branch-When-Needed system<br />(This is the system used by the Subversion project.)<br />Users commit their day-to-day work on /trunk.<br />Rule #1: trunk must compile and pass regression tests at all times. <br />Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.<br />Rule #3: if rules #1 and #2 come into conflict (i.e. impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets<br />Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.<br />Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.<br />
  25. 25. Overview<br />