How to create a local SVN Repository and connect to it using tortoise svn?

Some Bla Bla Bla’s:

Programmers like me sometimes wonder how can we create the local SVN repository. Most of the time we are connecting to already available repositories anyways like the one at your office or to some sites on the internet like Google Code. I recently ran into questions as I wanted some of my local codes to be versioned. I was publishing android apps, and as I kept updating the app, I really wanted to have my code versioned.

Then I discovered it was as easy as 123.

Real Solution:
Here is what you need to do (if you already have a tortoise svn installed, you dont even need to download anything.)

  1. Install tortoise svn from CollabNet (
  2. Create a directory anywhere on your local machine where you want to create the repository.
  3. Right click on the directory and choose Tortoise SVN > Create repository here

Your repository is now created locally!!!.

How to connect to it?

Just like you would with any other repositories. If I had created a repository on my desktop folder “MySVNRepo”, the following would be the repository location:

file:///C:/Documents and Settings/sanjaalcorps/Desktop/MySVNRepo

Once connected, you can do regular stuffs like creating folder, checking in to repository, checking out from the repository etc.

Well, I always thought I need to have a separate server installed for svn – but I figured out my thoughts had been foolish all these years.

How to find a list of files modified between two subversion revisions?

Starting with a background before I get into the details, I work on large projects that sometimes run over a year. We normally start from a clean branch out of the trunk at the time of development initiation. I have 8 developers working with me and we end up modifying quite a few files per day. Maintaining a accurate list of files modified manually for the project is a real pain. But when the project development completes, one of the things that we need to present back to the Application Team is something called “Deliverable Document” that outlines what files were modified and a summary of changes that were done on those files.

For few of the projects that I worked on, we did maintain this manual list of added/modified/deleted files. The problem with that is if any developer knowingly or unknowingly forgets to update the list with his/her files, the list becomes inaccurate. Then I started thinking to myself, there got to be a better way. We use subversion. Everytime we commit a file, the developers do put a note on what modifications were done on the files that they are committing. Since subversion maintains revisions, I started thinking there should be a way to get this list from the start of the project to the end of it with all those commit notes entered by developers for each revision. Then I found out a solution.

You will need a command line svn tool, if you don’t have already. I used Slik SVN. Since my svn clients (tortoiseSVN and Subclipse) use subversion 1.7.4, I downloaded the matching version.

I started experimenting with the svn diff command. I was able to produce a difference between two versions. But that’s not what I wanted. I didn’t want to know specific lines of code changes within each files.

svn diff -r 43099:45207

Then I started experimenting with the svn log command. But the following command I used produced only the commit notes between those two revisions.

svn log -r 43099:45207

Researching and experimenting further, I found out that svn log command takes a -v parameter which produces a list of files modified. Bingo ! That’s what I needed.

svn log -r 43099:45207 -v

But I had over 500 files modfied and the files were spit out on the console. I really wanted them to be exported on a file. I accomplished that by adding extra out stream parameters to the command.

svn log -r 43099:45207 -v >>c:/diff.txt

I had exactly what I needed. Didn’t need to maintain the manual list.

Here is the sample file that was generated by running this command (well I had to strip off several files from the results)

It however comes with extra work. If you modified the same file over multiple revisions. It will list those files multiple times with notes for each revision.

I simply use excel spreadsheet to consolidate those files and notes. But it’s better than having a probably incorrect list of files.

When the projects are long running, we do sync the code from trunk on bo-weekly basis after the production release. When merging from another branch occurs, this output produced by running commands above contains a definitive indication of where it got merged from – so those files could potentially be excluded from your deliverable (If you did not modify the same file with your project)

How to build a specific SVN (Subversion) revision in Hudson and Jenkins

Think about a scenario where you are working on some functionality of a project and committed a partially completed functionality to the subversion (probably because you were told Commit Early, Commit Often for continuous integration if you are working on an agile team). Now, you don’t want to, however, build and deploy the latest code to your test environment because some of the features are not ready yet. You are still working on those. In that case, if you need to do a build, you might wonder how to run a build from old and probably stable revision in your repository.

This is exactly what I am going to show you here.

I am hoping you are already using a subversion plugin to checkout the code, if not the plugin is available for Hudson at the following URL. Jenkins also has similar plugin.

Once you have installed this plugin, go to ‘Configure’ your Hudson Job and scroll down to Source Code Management section. Underneath subversion in that section (see the picture below), there is a field where you specify the repository URL. If you provide the plain URL to your subversion branch/trunk/tag, it will always pull the latest code from that branch/trunk/tag.

But you want to specify a specific revision,then you can append @revision at the end of the url. Where ‘revision‘ is your actual revision number.

For a fictitious svn url below, Hudson will always pull the latest code from the forexpro branch.

If you just need a revision 234, then the url you specify here would be

There are also other parameters that you can pash to this URL.e.g.

The above url builds with latest revision in the repository.

The above url builds with the 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.

The above url builds with the most recent revision prior to, or equal to, BASE, in which an item changed.

The URL above builds with the revision immediately before the last revision in which an item changed. Technically, this boils down to COMMITTED-1.