SVN Most Useful Commands

Subversion is a free/open-source version control system.

A tree of files is placed into a central repository.

The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories.
This allows you to recover older versions of your code, or examine the history of how your code was changed.

SVN client program which manages local reflections of portions of that versioned data which is called as working copy.

SVN Checkout – Create working copy

Checkout command is used to download sources from SVN repository to working copy.
 
SVN checkout creates the working copy, from where you can do edit, delete, or add contents. You can checkout a file, directory, trunk or whole project.

$ svn checkout/co URL PATH

When you do a checkout, it creates hidden directory named .svn, which will have the repository details.

SVN Commit – Save changes to the repository

Whenever you do changes to the working copy, it will not reflect in SVN server. To make the changes permanent, you need to do SVN commit.

$ svn commit -m "log messages"

SVN List – Lists directory entries

svn list is useful when you want to view the content of the SVN repository, without downloading a working copy.
 
lists all the files available in the given URL in the repository.
  
$ svn list url

When you execute svn list command with –verbose option it displays the following information.

Revision number of the last commit
Author of the last commit
Size (in bytes)
Date and time of the last commit 

$ svn list --verbose https://www.ctechz.com/svn/project/trunk

 16 ctechz  28361  Apr 16 21:11 README.txt
 21 ctechz   0        Apr 18 12:22 INSTALL
 22 ctechz         Apr 18 10:17 src/

SVN Add – Add a new file to SVN repository

When you want to add a new file (or directory) to the repository you need to use SVN add command. 

The repository will have newly added file, only when you do SVN commit. Now let us add a new file called “ctechz” to our repository.

* Create a file in local working copy
touch ctechz

* Add the file into SVN repository

svn add filename will add the files into SVN repository. From working copy

$ svn add ctechz
A         ctechz

* Commit the added file
Until you commit, the added file will not be available in the repository.

$ svn commit -m "Adding file ctechz" projectURL  
  ------- if from working dir it will upload automatically
Adding         ctechz
Transmitting file data .
Committed revision 84.

SVN Delete – Removing a file from repository

SVN delete command deletes an item from the working copy (or repository). File will be deleted from the repository when you do a SVN commit.

$ svn delete URL

$ svn delete ctechz  -- it will remove the recently created file

$ svn commit -m "Deleting ctechz file" ctechz
Deleting       ctechz
Committed revision 85.

SVN Diff – Display the difference

SVN diff displays the differences between your working copy and the copy in the SVN repository. You can find the difference between two revisions and two paths etc.

$ svn diff filename
$ svn -r R1:R2 diff filename

The above example compares the filename@R1 and filename@R2.

Now the content of the file ctechz will be,

# cat ctechz
testing

now edited the content of ctechz file from testing to tester, which is shown below using the svn diff command.

$ svn diff ctechz
Index: ctechz
--------------------------------
--- ctechz   (revision 85)
+++ ctechz   (working copy)
@@ -1 +1 @@
-testing
+tester 

SVN Status – Status of the working copy

Use svn status command to get the status of the file in the working copy. 

It displays whether the working copy is modified, or its been added/deleted, or file is not under revision control, etc.

$ svn status PATH

The following example shows the status of local working copy,

$ svn status /home/ctechz/cfg
M        /home/ctechz/cfg/ftp_user.cfg
M          /home/ctechz/cfg/ctechz 

‘M’ represents that the item has been modified.  Check for “svn help status” for more options.

SVN Log – Display log message

SVN remembers every change made to your files and directories. To know all the commits made in a file or directory, use SVN log command.

$ svn log PATH

$ svn log ctechz(or project path)

SVN Move – Rename file or directory

This command moves a file from one directory to another or renames a file.

$ svn move src dest

The file will be moved on your local working copy immediately (as well as on the repository after committing).

$ svn move ctechz new-ctechz

Now the file is renamed only in the working copy, not in the repository. To make the changes permanent, you need to commit the changes. 

$ svn commit -m "Renaming ctechz to new-ctechz" new-ctechz

SVN Update – Update the working copy

svn update command brings changes from the repository into your working copy. If no revision is specified, it brings your working copy up-to-date with the HEAD revision. Otherwise, it synchronizes the working copy to the revision given in the argument.

Always before you start working in your working copy, update your working copy. So that all the changes available in repository will be available in your working copy. i.e latest changes.

$ svn update PATH

In case some other user added/deleted file in Repository, your working copy will not have those files by default, until you update your working copy.

$ svn update
A  new/user2
A  new/web1
Updated to revision 816

SVN (Subversion) trunk,branches,tags

Trunk: Main development area. This is where your next major release of the code lives, and generally has all the newest features.

Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.

Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code.

For example, let's say you start a new project, so you're working on what will be 1.0 in trunk. Once 1.0 is finished, you branch trunk into a new "1.0" branch, and create a "1.0" tag. Now work on what will eventually be 1.1 continues in trunk. 

You come across some bugs in the code, and fix them in trunk, and then merge the fixes over to the 1.0 branch. You may also get bug reports for 1.0, and fix the bugs in the 1.0 branch, and then merge them back to trunk. Sometimes a bug can only be fixed in 1.0 because it is obsolete in 1.1. It doesn't really matter, the only thing is you want to make sure that you don't release 1.1 with the same bugs that have been fixed in 1.0. Once you find enough bugs (or maybe one critical bug), you decide to do a 1.0.1 release. So you make a tag "1.0.1" from the 1.0 branch, and release the code. At this point, trunk sill contains what will be 1.1, and the "1.0" branch contains 1.0.1 code. The next time you release an update to 1.0, it would be 1.0.2.

Eventually you are almost ready to release 1.1, but you want to do a beta first. In this case, you likely do a "1.1" branch, and a "1.1beta1" tag. Now, work on what will be 1.2 (or 2.0 maybe) continues in trunk, but work on 1.1 continues in the "1.1" branch. Once you release 1.1 final, you do a "1.1" tag from the "1.1" branch.

You can also continue to maintain 1.0 if you'd like, porting bug fixes between all 3 branches (1.0, 1.1, and trunk). The important take away is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.

Another use of branches is for features. This is where you branch trunk (or one of your release branches) and work on a new feature in isolation. Once the feature is completed, you merge it back in and remove the branch. The idea of this is when you're working on something disruptive (that would hold up or interfere with other people from doing their work), something experimental (that may not even make it in), or possibly just something that takes a long time (and you're afraid if it holding up a 1.2 release when you're ready to branch 1.2 from trunk), you can do it in isolation in branch. Generally you keep it up to date with trunk by merging changes into it all the time, which makes it easier to re-integrate (merge back to trunk) when you're finished.

Also note, the versioning scheme I used here is just one of many. Some teams would do bug fix/maintenance releases as 1.1, 1.2, etc, and major changes as 1.x, 2.x, etc. The usage here is the same, but you may name the branch "1" or "1.x" instead of "1.0" or "1.0.x". 

The trunk is the development line that holds the latest source code and features. It should have the latest bug fixes in it as well as the latest features added to the project.

The branches are usually used to do something away from the trunk (or other development line) that would otherwise break the build. New features are often built in a branch and then merged back into the trunk. Branches often contain code that are not necessarily approved for the development line it branched from. For example, a programmer could try an optimization on something in a branch and only merge back in the development line once the optimization is satisfactory.

The tags are snapshots of the repository at a particular time. No development should occur on these. They are most often used to take a copy of what was released to a client so that you can easily have access to what a client is using.

SVN commands Help

svn checkout file:///tmp/repos/test  ------- checking out the repository

svn add testdir --------- When adding a directory, the default behavior of svn add is to recurse

svn add --non-recursive otherdir ---- You can add a directory without adding its contents

svn add * --force ------

svn cat http://svn.red-bean.com/repos/test/readme.txt ------- If you want to view readme.txt in your repository without checking it out

svn checkout file:///tmp/repos/test mine --- Check out a working copy into a directory called mine

svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz ------ Check out 2 different directories into two separate working copies

svn checkout file:///tmp/repos/test  file:///tmp/repos/quiz working-copies ---- Check out 2 different directories into two separate working copies, but place both into a directory called working-copies.

svn propset svn:mime-type image/jpeg foo.jpg ---- Set the mimetype on a file

svn propset svn:executable ON somescript  -------- On a UNIX system, if you want a file to have the executable permission set

svn propset --revprop -r 25 svn:log "Journaled about trip to New York."  ----------- If you made a mistake in a log message for a particular revision and want to change it, use --revprop and set svn:log  to the new log message.

svn delete myfile --------- Using svn to delete a file from your working copy merely schedules it to be deleted. When you commit, the file is deleted in the svn commit -m "Deleted file 'myfile'."  repository.

svn delete -m "Deleting file 'yourfile'" file:///tmp/repos/test/yourfile   ---------- Deleting a URL, however, is immediate, so you have to supply a log message     

svn status wc ------- This is the easiest way to find out what changes you have made to your working copy

svn status --show-updates wc -------- if you want to find out what files in your working copy are out-of-date, pass the --show-updates switch.

svn status --show-updates --verbose wc

svn update ------- Pick up repository changes that have happened since your last update

svn update -r30 ---------- You can also update your working copy to an older revision.

svn commit -m "added howto section." ------- Commit a simple modification to a file with the commit message on the command line and an implicit target of your current directory.

svn commit -F msg foo.c ----- Commit a modification to the file foo.c with the commit message in a file named msg

svn commit -m "removed file 'c'." ----- To commit a file scheduled for deletion

svn move foo.c bar.c  ---------- Move a file in your working copy

svnadmin dump /usr/local/svn/repos ---- Dump your whole repository.

svnadmin dump /usr/local/svn/repos -r 21 --incremental ----- Incrementally dump a single transaction from your repository

svnadmin recover ---- Recover a hung repository, Bring a repository database back into a consistent state.

svnadmin dump /path/to/reponame > /tmp/reponame.dump ; scp -rp /tmp/reponame.dump user@server.domain.com:/tmp/  ------- dump

svnadmin load /path/to/reponame < /tmp/repo1.dump  ------------ restoring svn repository from dump 

 SVN Dump 

# svnadmin dump /usr/local/svn/repos > full.dump ---- Dump your whole repository.

# svnadmin dump /usr/local/svn/repos -r 21 --incremental > incr.dump ---- Incrementally dump a single transaction from your repository.

# svnadmin recover --------- Recover a hung repository, Bring a repository database back into a consistent state.

# svnadmin dump /path/to/reponame > /tmp/reponame.dump ; scp -rp /tmp/reponame.dump user@server.domain.com:/tmp/ ------- dump.

# svnadmin load /path/to/reponame < /tmp/repo1.dump --- restoring svn repository from dump.

# cd /var/www/svn/
# svnadmin create test2
# svnadmin load /var/www/svn/test2 < svn.dump (dump of script repo)

To Restore Svn Dump

# svnadmin create /var/www/SVN/Project
# svnadmin load /var/www/SVN/project < project4.dump
# svnadmin load /var/www/SVN/project < project4_trunk.dump ----> If need to restore only the trunk. 

Importing from remote machine

svn import --username ctechz workingDir http://192.168.0.54/projectName/trunk -m "prodmlserver"
if u are committing files for the first time do this much.

if any changes are made by developers by checkout it and we want to add it into the server use the 'svn add' cmd

if we modify any changes in checkout file, just specify # svn update --- so that the updation will get for all the users if add and folders or touched any files give # svn add before committing them 
# svn ci

Renaming an SVN(Subversion) Repository 

SVN is document versioning software commonly used by software developers as a repository for source code.

Issue: Renaming a Repository
Here's the scenario: We have an SVN repository and we want to change it's name.

The solution: svnadmin dump & svnadmin load

The correct way to do this is to actually create a repository with the new name, and then import all revisions from the old repository into the newly created one. This way, all the revision history will be preserved

So, first we create a repository with the new name. Assuming /path/to/new/repository/ is the path where you want the new repository to be created, and <new-repo-name> is the new name, the command would look like this..

# svnadmin create /path/to/new/repository/<new-repo-name>

Then we dump all the data from the old respository into a file called old-repo.dump. We will assume /the/path/to/old/repository/ is the path to the repository and that the old repository was called old-repo-name.

# svnadmin dump /the/path/to/old/repository/<old-repo-name> > old-repo.dump
 
Now, we can import the dump file into the newly created repository. In order to to that we use the SVN load command.

# svnadmin load /the/path/to/new/repository/<new-repo-name> < old-repo.dump
NOTE: One thing to note is that for this method to be successful, the newly created repository has to be empty. Otherwise you may get all sorts of errors and/or funny results.

The other observation that I would make is that in case of a large project, this process may take a while and the resulting dump file and new repository may be rather large.

To remove a directory from svn 

# svn remove dir
# svn list file:///var/www/svn/script/trunk/
# svn ci -m "commit"
# svn list file:///var/www/svn/script/trunk/

To re-name a directory in svn 

# svn ren sqlbkp.sh sqlbkp1.sh
# svn list file:///var/www/svn/script/trunk/
# svn ci -m "commit"
# svn list file:///var/www/svn/script/trunk/

To backup only your latest revision

First you need to find out the latest revision number from your repository. To do that just run below command:

# svnadmin verify [REPO_PATH]
 
It will list out the revision number and the most bottom will be your latest revision number. That will be referenced by [LATEST_REVISION_NUM] from now on.

Run below command to backup only the latest revision from [REPO_PATH].
 
# svnadmin dump -r [LATEST_REVISION_NUM] [REPO_PATH] > [DUMP_FILE_PATH] 

The version number is just a shortcut to the date at which the project is stamped. Let's now get a copy of the previous version(assuming the revision number is 4)
 
cd /tmp/
$ svn checkout -r 3 file:///home/user/svn project
U project/project/trunk/src/main.cpp
U project/project/trunk/src/Makefile
D project/project/trunk/src/class.cpp
D project/project/trunk/src/class.h
Checked out revision 3.

Have a closer look at the output. It shows how clever svn is. We asked for version 3 but because of our previous command, the version 4 is already in /tmp.

No problem, svn does all the necessary things and indicate them : the main.cpp and Makefile are updated and the class.{h,cpp} files are deleted.

How to setup an SVN Repository

# yum install httpd subversion mod_authz_ldap mod_dav_svn
 
# mkdir /var/www/svn
# cd /var/www/svn
 
# svnadmin create Project1
# ls Project1/
# cd /tmp/
 
# mkdir Project1
# cd Project1/
 
# mkdir branches tags trunk
# cd ..
 
# svn import Project1/ file:///var/www/svn/Project1 -m "Importing new project"
 
# svn list file:///var/www/svn/Project1/
# rm -rf Project1
# cd /var/www/svn/
 
# chown apache. -R *
# cd ..

# vim /etc/httpd/conf.d/subversion.conf
[
Location /Project1
DAV svn
SVNPath /var/www/svn/Project1

# Limit write permission to list of valid users.
# Require SSL connection for password protection.
# SSLRequireSSL

AuthType Basic
AuthzSVNAccessFile /etc/httpd/password/svnauthz.conf
AuthName "LDAP AUTHENTICATION"
AuthBasicProvider ldap
AuthLDAPURL ldap://192.168.0.20:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)
# AuthUserFile /path/to/passwdfile
Require valid-user
order allow,deny
Allow from all

Location
]

# mkdir /etc/httpd/password

# vim /etc/httpd/password/svnauthz.conf

[
[groups]
others = rick
linux = ctechz, btechz

[Project1:/]
@systemsteam = rw
@others = r

]

# service httpd restart

 SVN Client

tortoisesvn ------ for windows
smartsvn ------- for linux

# svn co http://192.168.0.20/Project1/trunk/
 
# cd trunk
# cp bin trunk
# svn add bin
 
# svn ci bin m "Adding project"
# svn ci test/ http://192.168.0.19/Project1/trunk/ -m "Adding project"
 
# cd
# svn import --username aby test/ http://192.168.0.19/Project1/trunk/ -m "Adding Project" ------ import to add a new project
 
# svn list http://192.168.0.19/Project1/trunk/

Setting UP a new SVN Project 

# cd /var/www/test
# ls
 
# svnadmin create PG_Script
 
# cd /tmp/
# mkdir PG_Script
# cd PG_Script/
 
# mkdir trunk branches tags
 
# ls
# cd
# cd /tmp/
 
# svn import PFG_Script/ file:///var/www/test/PG_Script/ -m "Importing Script"
 
# rm -rf PG_Script/
# cd /var/www/test
# ll
 
# chown apache.apache PFG_Script -R
 
# ll
# cd
 
# vim /etc/httpd/conf/httpd.conf
 
# vim /etc/httpd/passwd/svnauthz.conf
 
# /etc/init.d/httpd reload

# svn import --username aby test/ http://192.168.0.19/Project1/trunk/ -m "Adding Project" ------ import to add a new project

SVN check-out and check-in 

# svn co file:///var/www/svn/script/trunk/
# cp sqlbkp.sh /root/trunk/
# cd trunk/
 
# svn add sqlbkp.sh
# svn ci -m "import"

 Make a New dir

# mkdir dir
# cd dir/
# touch 1 2 3
# mkdir g t r
# cd .. 

# svn add dir
# svn ci -m "import"
# svn list file:///var/www/svn/script/trunk/