Post on 21-Aug-2015
Subversion and TortoiseSVN – a Basic PrimerSubversion and TortoiseSVN – a Basic Primer
Blake Medulan
2008
What is it?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 itWhy 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
VocabularyVocabulary
• 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.
VocabularyVocabulary
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
TortoiseSVNTortoiseSVN
• 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
TortoiseSVNTortoiseSVN
• Once a directory is identified as version controlled, the
following icons are used
Checkouts and CommitsCheckouts 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” operationThe “Checkout” operation
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
STEPS
The “Checkout” operationThe “Checkout” operation
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.
STEPS
The “Commit” operationThe “Commit” operation
• 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!
STEPS
Rename Files and FoldersRename 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 FoldersDelete 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 FoldersAdding 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
UpdatesUpdates
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 scenarioConflicts – 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
ConflictsConflicts
When you try to commit your file you get the following message
You then run an Update operation, and you will see the following:
ConflictsConflicts
After you click OK, the folder containing main.cpp will now have several new, non-versioned
files in it:
1
2
3
4
ConflictsConflicts
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.
ConflictsConflicts
You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit
Conflicts:
ConflictsConflicts
You can now right-click on the file main.cpp, and under the TortoiseSVN option, select Edit
Conflicts:
BranchingBranching
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.
BranchingBranching
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.
BranchingBranching
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.
OverviewOverview