Subversion
Upcoming SlideShare
Loading in...5
×
 

Subversion

on

  • 1,182 views

 

Statistics

Views

Total Views
1,182
Views on SlideShare
1,176
Embed Views
6

Actions

Likes
1
Downloads
41
Comments
0

2 Embeds 6

http://blakedot.blogspot.com 3
http://blakedot.blogspot.ca 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Subversion Subversion Presentation Transcript

  • Subversion and TortoiseSVN – a Basic Primer
    Blake Medulan
    2008
  • What is it?
    Subversion (abbreviated SVN) is an open source version control system that facilitates source code development by multiple software developers.
    • Web Access
    • SSH
    • Windows Shell
  • Why we use it
    SVN allows us to easily
    maintain backups of source code
    automate deployment
    keep copies of every single version of the code
    prevents developers from overwriting each other's work.
    roll back to previous versions of code
  • 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.
  • 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
  • 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
  • TortoiseSVN
    • Once a directory is identified as version controlled, the following icons are used
  • Checkouts and Commits
    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)
    Updated code can then be 'committed' back to the SVN repository as a new version of the source code, and
    Subsequent attempts to check out the latest version of the code will acquire this newer, updated version.
  • 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
  • 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.
  • The “Commit” operation
    STEPS
    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....
    • 2. Enter log message
    Only use accurate, descriptive comments so others can understand how the new version of code you are creating differs from the previous version!
  • 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
  • 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:
  • 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
  • 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.
  • 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
  • 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:
  • Conflicts
    After you click OK, the folder containing main.cpp will now have several new, non-versioned files in it:
    3
    1
    4
    2
  • 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.
  • Conflicts
    You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:
  • Conflicts
    You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit Conflicts:
  • 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.
  • 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.
  • 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.
  • Overview