This document provides an overview of Subversion and TortoiseSVN, including: - What Subversion is and why it is used for version control and maintaining backups of source code. - Key concepts like commits, checkouts, branches, and conflicts. - How TortoiseSVN integrates with Windows Explorer to allow access to SVN repositories. - Steps for common operations like checkouts, commits, renaming/deleting files, adding files, and resolving conflicts. - Different approaches to branching like never-branching, always-branching, and branch-when-needed.

1. Subversion and TortoiseSVN – a Basic Primer Blake Medulan 2008

3. SSH

5. Vocabulary SVN : abbreviation for subversion Head Revision: The latest (or “youngest”) revision in the repository. Conflict: Two competing versions of the same file Working Folder: Folder (local or server) that you check out the code to in order to edit Commit : Publish new files to repository 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.

6. Vocabulary 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. Prev: The revision immediately before the last revision in which an item changed. Technically, this boils down to COMMITTED#1. WebDAV: Distributed Authoring and Versioning.” RFC 2518

7. TortoiseSVN TortoiseSVN is a Windows shell extension that allows you to access SVN repositories within Windows Explorer. 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

9. The “Checkout” operation STEPS 1. Create a working folder locally 2. Right click on folder select SVN Checkout 3. Enter repository location (http://10.1.1.250/project_xxx) (http://subversion.webfeat.mci/project_xxx) 4. Select working folder

10. The “Checkout” operation STEPS 5. Enter your username and password 6. Checkout process begins 7. Working folder now contains latest version The green check means that the folder contains SVN files and is version controlled.

12. Rename Files and Folders 1. Checkout the file or folder to your machine 2. Right-click on the file or folder, and select the menu option SVN Rename 3. Type in the new name, and the icon for the file or folder will change to; 4. Run a Commit and the repository will be updated with the new name

13. Delete Files and Folders 1. Checkout the file or folder to your machine 2. Right-click on the file, and select the Delete... option from the TortoiseSVN menu:

14. Adding Files and Folders 1. Checkout the latest version 2. Move the new file(s) and folder(s) to the location you want them in the repository 3. Right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN Add. 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

15. Updates 1. Update your local snapshot of the repository to the latest version available by running an Update Operation. 2. Right-click on a folder containing versioned files and folders in it, and select the SVN Update... menu option. NOTE: Only the files already checked out will be updated (or deleted, if they were deleted in the repository since you last updated) 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.

16. Conflicts – the scenario 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.) 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

17. Conflicts When you try to commit your file you get the following message You then run an Update operation, and you will see the following:

18. Conflicts After you click OK, the folder containing main.cpp will now have several new, non-versioned files in it: 3 1 4 2

19. Conflicts main.cpp.mine This is what main.cpp v31 looked like after you changed it (no conflict markers). main.cpp.r31 This is what version 31 of main.cpp looked like (the file you checkout and then modified). main.cpp.r32 This is what the current version of main.cpp looks like (on the server). main.cpp During the Update operation, conflict markers were inserted into this file.

20. Conflicts You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:

21. Conflicts You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:

22. Branching The Never-Branch system (Often used by nascent projects that don't yet have runnable code.) Users commit their day-to-day work on /trunk. Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes. Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge. Cons: Chaotic development, code could be unstable at any time.

23. Branching The Always-Branch system (Often used by projects that favor heavy management and supervision.) Each user creates/works on a private branch for every coding task. When coding is complete, someone (original coder, peer, or manager) reviews all private branch changes and merges them to /trunk. Pros: /trunk is guaranteed to be extremely stable at all times. Cons: Coders are artificially isolated from each other, possibly creating more merge conflicts than necessary. Requires users to do lots of extra merging. Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.

24. Branching The Branch-When-Needed system (This is the system used by the Subversion project.) Users commit their day-to-day work on /trunk. Rule #1: trunk must compile and pass regression tests at all times. Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review. 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 Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare. Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

25. Overview