Subversion (SVN) is a very popular open source versioning system. It manages files, directories, and changes made to files and directories over time by single of multiple users. If you have the time to thoroughly learn SVN, the only book you should read is available online for free. It can be found at http://svnbook.red-bean.com. However, if all you want to do is get started with SVN within an hour, you have come to the right place.
A decade ago Concurrent Versioning System (CVS) was the most-widely used versioning. It is built on Revision Control System (RCS) and thus inherits its flaws and this inheritance is precisely the reason it is very difficult to fix these flaws in CVS. SVN was created to overcome the flaws of CVS. It offers all the benefits of CVS without its flaws.
The purpose of versioning systems is to facilitate collaborative editing and sharing between different participants while making sure that no one accidentally overwrites someone else's work. Versioning systems also ensure that everyone has the current version of the resource, helps in avoiding duplication, and enables users to track changes. A version control system is a necessity for any software development project employing multiple programmers.
Versioning system use either the Locking (Lock-Modify-Unlock) Model or the Nonlocking (Copy-Modify-Merge) Model. The locking model allows only one user to edit a file at a time. This is accomplished by using locks. While someone is editing a file, it is locked and other users can only view it. Once a user is finished editing a file, the file is unlocked and available for editing by other users. User's are often frustrated with Locking Model's restrictiveness e.g. a user is editing a file and then runs off to a 2 hour meeting while another user can't progress because he needs to edit this file.
Nonlocking Model is used by SVN, CVS and many other versioning systems. In this model, every user works on a local copy of the repository rather than on the repository itself. Once a user is done editing a file, he commits it to the repository. All other users can update their local copy by updating their local copies. If two users are working are editing a file simultaneously, their changes are merged into a file. Merging is not possible with binary files such as images and video. In such cases, SVN allows users to use a locking model.
Setting up svn repository
SVN stores all project files in a repository. Every user checks out files from this repository and uploads their modification to this repositories. This way every user has the most recent version of the project files.
Step 1: Create repository The repository holds all files in a project.
cd ~ svnadmin create svnrespos svn mkdir file:///home/me/svnrepos/trunk file:///home/me/svnrepos/branches file:///home/me/svnrepos/branches -m "creating repository layout"
To see what you created
svn list file:///home/me/svnrepos
Step 2: Import project into the repository Here we import project files into the SVN repository. Assuming that the project files are in ~/myproject and it contains files a.xml and a.dtd
cd ~ svn import myproject file:///home/me/svnrepos/trunk -m "importing project"
To see what was imported
svn list file:///home/me/svnrepos/trunk
Step 3: Check out a working copy Every collaborator works on his working copy rather than the repository itself.
cd ~ svn checkout file:///home/me/svnrepos/trunk xml-project
This would create a directory called xml-project and copy all project files from the repository to this directory. User can edit these files.
SVN is a very feature rich software but you only need a few commands on a daily basis. These are covered here:
- svn update: update working copy i.e. copy latest revisions from repository to your working copy
- svn commit: copy your changes to the repository
- svn add, svn delete, svn copy, svn move: self-explanatory
- svn revert: undo changes
SVN is a client-server application where the SVN repository serves the tasks of a server. It is a central storage place which stores information in the form of a filesystem tree. Users share data by reading and writing to the repository. The repository keeps track of all changes written to the file i.e. modifications to the files, file contents, and directory structure. Users see the latest version of the filesystem by default but they can view every change ever make to the contents of the repository.
SVN working copy
SVN working copy is just another directory on your system. You can edit these files any way using any software tool you desire. Your changes will only be incorported into the repository only when explicity instruct SVN to do so using "svn commit" command. Changes made by other users will only be incorporated into your working copy only when you explicitly instruct SVN to do so using "svn update". You can have multiple working copies on your system. SVN creates and maintains extra files inside .svn directory (inside your working copy) which are necessary for SVN to performs its tasks such as update, commit, etc.
svn diff lists all differences two files or a set of files
$ svn diff file1 file2
-r option shows difference between two versions of a files or set of files
$ svn diff -r5:10 some_directory
This code shows all changes made to the directory and all its contents between version 5 and version 10
$ svn diff --summarize some_directory
This code only lists files which have changes, not the details of what has changed inside them.
To get help on any svn command, all the user needs to do is type:
$ svn help usage: svn <subcommand> [options] [args] Type
Following is a list of subcommands. Aliases are in parentheses. Aliases were created to make SVN friendlier for CVS users switching to SVN.
add blame (praise, annotate, ann) cat checkout (co) cleanup commit (ci) copy (cp) delete (del, remove, rm) diff (di) export help (?, h) import info list (ls) log merge mkdir move (mv, rename, ren) propdel (pdel, pd) propedit (pedit, pe) propget (pget, pg) proplist (plist, pl) propset (pset, ps) resolved revert status (stat, st) switch (sw) update (up)
$ svn help add add: Put files and directories under revision control, scheduling them for addition to repository. They will be added in next commit. usage: add PATH [PATH [PATH ... ]] Valid options: --targets arg : pass contents of file ARG as additional args -N [--non-recursive] : operate on single directory only -q [--quiet] : print as little as possible
Viewing and managing changes
svn status The svn status command provides an overview of changes made in the working copy since the last update or commit. svn status run at the top of the working copy detects all changes made in the tree. svn status run with a specified path gives information relevant to that address.
svn status database/flatfile
The specified path could be directory of file
svn status -v
With the -v option, svn status shows every file even if it wasn't changed
svn status -u
With the -u option, svn status shows outdated files.
Following is a sample output of svn status
A 45 23 user1 testscript.php M 45 20 user2 index.html
Take a look at the left most column. Following is these letters mean:
A: scheduled for addition C: conflict detected, resolve before committing D: scheduled for deletion M: file contents modified
The second column is the revision number, followed by revision where the file was changed, user name of the person who made the modification, and file name.
copying svn repository to another server
Following are steps to copy svn repository from one server to another.
$ svnadmin dump /path/to/repository > repository.dump $ scp repository.dump email@example.com:~/ $ svnadmin create new-repository $ svnadmin load new-repository < repository.dump $ svnadmin checkout file:///path/to/repository /path/to/working-copy
- First line creates a repository dump
- Second line copies the dump file to the new server
- creates new repository
- loads the repository dump into the new repository
- create a working copy of the new repository
FSFS vs BDB
FSFS and BDB are Subversion filesystem implementations. Traditionally Berkeley DB (BDB) was the standard filesystem used by Subversion. FSFS was developed at MIT. It solves many serious concerns with BDB such as data corruption and added improvements such as smaller space requirements. Now the FSFS is the standard, the default setting, and recommended by Subversion developers. How is FSFS better than BDB:
- platform independent
- smaller repositories
- can host on network filesystem
- insensitive to interruptions
- other geeky details
Installing and using kdesvn
The best SVN GUI client is Tortoise SVN. Unfortunately, it is not a viable solution on Ubuntu. KDESVN is a good alternate to Tortoise SVN.
Installing kdesvn To install,
$ sudo apt-get install kdesvn
You might also be prompted to install Subversion, kompare and a few other libraries.
Running kdesvn Once the installation is complete, run
on the commandline to start kdesvn.
Adding kdesvn to right-click menu Create a file ~/.gnome2/nautilus-scripts/kdesvn.sh and add the following two lines of code:
#!/bin/sh kdesvn $1
Assuming that your shell in located at /bin/sh. Type:
if you do not know where the shell is installed. The assign execution privileges:
$ chmod 755 ~/.gnome2/nautilus-scripts/kdesvn.sh
In your file browser right click on any file or directory and you would see link for "open with kdesvn".
Creating a Subversion repository with kdesvn On kdesvn, click on File > Subversion Admin > Create and open new repository. A window would open. For Path to repository, type or browse to your address. For Type of repository, choose FSFS. For details on this, see FSFS vs BDB. Check only "create main folders" option.
Checking out a Subversion repository with kdesvn On the left window, select "trunk". The select Subversion > Repository > checkout current repository path. A window would open. Select target directory, choose revision, and uncheck "Append source url name to subfolder".