You use it by creating a new Screensaver object and simply attaching your show/hide functions to the onActive and onIdle events it fires. For example, let’s say you have a Lightbox type of element and want to display it when the user goes idle. You would do something like this:

// Lightbox pseudocode
var lightbox = new Lightbox();

// Screensaver
var moosaver = new Screensaver({
	onIdle:  lightbox.show,
	onActive: lightbox.hide,
	ttl: 15000 // 15 seconds till idle.
});

Download your own copy at the GitHub Repo or just copy and paste the code below. The repo has a bit of documentation if you need more info.

(function() {
	Screensaver = new Class({
		Implements: [Options, Events],
		options: {/*
			onActive: $empty,
			onIdle: $empty,*/
			events: ['click', 'keypress', 'mousemove', 'resize', 'scroll'],
			target: window,
			ttl: 10000
		},

		initialize: function(options) {
			this.setOptions(options);
			this.enabled = false;

			var target = document.id(this.options.target);
			this.options.events.each(function(ev) {
				target.addEvent(ev, this.reset.bind(this));
			}, this);

			this.monitor();
		},

		monitor: function() {
			this.timer = this.display.delay(this.options.ttl, this);
		},

		reset: function() {
			$clear(this.timer);
			if (this.enabled) {
				this.fireEvent('active');
				this.enabled = false;
			}
			this.monitor();
		},

		display: function() {
			this.fireEvent('idle');
			this.enabled = true;
		}
	});

	Element.implement({
		screensave: function(options) {
			options.target = this;
			return new Screensaver(options)
		}
	});
})();

Here’s a detailed example: Let’s say I visit this Reddit URL just as my connection flakes out:

http://www.reddit.com/r/programming/comments/a50gl/my_com_sci_professor_just_told_us_that_hes_never/

After a min or so of not resolving, OpenDNS kicks in and attempts to help out. It will convert that url to the following in the process:

http://guide.opendns.com/?url=www.reddit.com%2Fr%2Fprogramming%2Fcomments%2Fa50gl%2Fmy_com_sci_professor_just_told_us_that_hes_never%2F

Now I know that URL is valid, but now there’s no easy way to get back to it since the URL is all mangled. What can we do?

Javascript to the rescue! We simply use a bit of string manipulation on the url to figure out the original location and use the window.location style redirect to take us there. Simply drag this bookmarklet to your bookmarks bar to use. Here’s the relevant javascript code:

(function(){
	window.location = 'http://'+decodeURIComponent(document.location.search.substring(5));
})();

Well the answer is a lot simpler than it seems. The key to it all is the variable bandwidth pricing which means that once you’ve picked your slice size, your bandwidth usage will dictate which company you should host with. There are a couple other differences which I will point out below, but for the most part the server size and bandwidth use should take the bulk of the decision process.

I’ve created a simple table below which gives you the bandwidth limit at which Rackspace stops being the better deal. It’s based on the prices as of October 29, 2009 where Rackspace charges $0.22/GB and Slicehost charges $0.30/GB over your allotment. Simply pick your server size on the left and compare your expected bandwidth needs with the boundary.

Bandwidth limit where Rackspace is optimal.

Slice Size	Bandwidth
256 MB	If using less than 41.14 GB, pick The Rackspace Cloud
512 MB	If using less than 73.18 GB, pick The Rackspace Cloud
1024 MB	If using less than 119.09 GB, pick The Rackspace Cloud
2048 MB	If using less than 192.73 GB, pick The Rackspace Cloud
4096 MB	If using less than 340.00 GB, pick The Rackspace Cloud
8192 MB	If using less than 452.73 GB, pick The Rackspace Cloud
15872 MB	If using less than 450.91 GB, pick The Rackspace Cloud If using more than 6260.00 GB, pick The Rackspace Cloud

As you can see, Slicehost gives you a better deal when your bandwidth needs increase. I’ve used them both, and with the tools they offer and their pricing scheme, it feels like they are there to be used as web hosts. Rackspace on the other hand doesn’t bundle bandwidth and even prices their servers by the hour which leads to faster deploy/destroy cycles and more oriented towards apps.

The other differences have been debated before like the extra DNS records you can use in Slicehost, but I think these are minor details when compared to the savings you can get by using Rackspace for low bandwidth operations. All that being said, you can’t go wrong with either company

I originally used Radiant CMS to manage the content on my site but after I ran into a wall trying to get blog functionality to work, and more importantly since it was over-taxing my 256 MB slice, I decided to switch to WordPress.

Developing a site layout with WordPress on Coda turned out to be easier than I thought it would be. While the local previews might not work, it was easy enough to publish and preview changes on a test deployment while Radiant kept running. The only thing I wish I had at the time was autocompletion of WordPress functions so I decided to write a Mode for WordPress now that I had some spare time.

With autocompletion from my Mode and the Coda Clips from WPCandy.com, working on my site is much more streamlined. Download your own copy at WordPress.mode

Hooks

Svnserve has a nice system of hooks that let you execute any script you want at certain moments of a commit. Warehouse has a set of command line actions that let you synchronize the changesets so let’s make a hook which happens after a commit to synchronize the latest changes.

post-commit file

Let’s create the post-commit script:

cd ~/repositories
nano post-commit

Here’s the contents of the script:

#!/bin/sh
cd /home/demo/public_html/warehouse
rake warehouse:post_commit RAILS_ENV=production REPO_PATH=$1 REVISION=$2

As long as the repository and the subfolder have the same name, the repo is automatically chosen by Warehouse so to make things easy and to be able to use this same post-commit file everywhere, let’s keep those names consistent.

Now make the script executable:

chmod +x post-commit

hook your repositories

Finally, we’ll make a symbolic link to the post-commit hook from each of the repos’ hooks directories just like we did with the svnserve.conf files. Be sure to do this for any future repos you create.

ln -fs /home/demo/repositories/post-commit project1/hooks
ln -fs /home/demo/repositories/post-commit project2/hooks

Test it out

Let’s give the automatic syncing a try. Make some changes to your local copy of the repository and make a commit. This should behave normally but now when you revisit your repo in Warehouse, it will have magically been updated with the latest changes. Neat!

SVN Access Files

Let’s get Warehouse to create both our SVN access files (authz) and user/password files (passwd) automatically when changes are made from the web interface. Let’s start with the easy one…

Build authz configuration file

Warehouse let’s you set per-directory access rules on every repo it manages. This allows you to fine tune access for any and all of your users easily. It will also output these rules to a file which svnserve can read and understand to limit access for commits and checkouts, etc.

Let’s set this up, visit the admin settings tab at http://code.example.com/admin/settings. Set the “Shell command to run when permissions are updated” to:

rake warehouse:build_config RAILS_ENV=production CONFIG=/home/demo/repositories/authz

All this does is tell Warehouse to write the permissions we configure in Warehouse to the authz file in our repositories folder.

Re-enable authz-db in svnserve

Now we must tell svnserve to actually use this authz file so hop back into the svnserve.conf file and make the change by uncommenting the authz-db line. It should now look like this:

[general]
anon-access = none
auth-access = write
password-db = /home/demo/repositories/passwd
authz-db    = /home/demo/repositories/authz
realm       = Example Repository

That’s it! Now you can manage repository access right from the Warehouse GUI. Give it a try by changing a permission from the Access pane and seeing if the authz file gets updated correctly.

Note that the default access for new repos in Warehouse is read-only for the primary user so be sure to update that as needed.

Write the passwd file

Warehouse has a mechanism to write to htpassword files (appropriately called rake warehouse:build_htpasswd). These files look just like the passwd file we created in Act I except they don’t include the [users] header. The [users] header is necessary for svnserve to read the file so we must coax Warehouse to add this header. Additionally, Warehouse is configured to write passwd files in a hashed form but svnserve requires plaintext files. So let’s fix this.

Enable Plain Text passwords

Hop back into the Settings pane of the Admin page. Click on “More settings…” at the bottom left and look for the “Authentication Scheme” drop down under the Password Settings section. Choose “Plain” from the drop down and save the new settings. Now you must change your user passwords to make sure they are saved in plain text this time around.

Change Warehouse’s htpasswd method

Now we will actually edit the Warehouse app to get the functionality we want. This isn’t too hard, but unfortunately any updates will temporarily break the password mechanism. So be sure to change this file again if you ever update/change Warehouse. Let’s get to the right file first:

cd ~/public_html/warehouse
cd lib/warehouse

edit command.rb file

Open up the command.rb file:

nano command.rb

and look for the following method (line 98):

def write_users_to_htpasswd(users, htpasswd_path = nil)
    if htpasswd_path.nil?
        htpasswd_path = users
        users         = connection[:users]
    end

    users = users.select(:login, :crypted_password) if users.is_a?(Sequel::Dataset)
    open htpasswd_path, 'w' do |f|
        users.each do |user|
            next if user[:login].to_s == '' || user[:crypted_password].to_s == ''
            f.write("%s:%s\n" % [user[:login], user[:crypted_password]])
        end
    end
    puts "Wrote htpasswd file to '#{htpasswd_path}'"
end

This baby handles the writing of the htaccess file so we simply tell it to write a [users] line before cycling through each user and password. Simply add the following code:

f.write("[users]\n")

To the “open htpasswd_path” loop like this:

open htpasswd_path, 'w' do |f|
    f.write("[users]\n")
    users.each do |user|
        next if user[:login].to_s == '' || user[:crypted_password].to_s == ''
        f.write("%s:%s\n" % [user[:login], user[:crypted_password]])
    end
end

save and restart

Now save the file and restart Warehouse.

sudo /etc/init.d/thin restart

test it out

And that’s it. Let’s give it a try by running the following command:

cd ~/public_html/warehouse
rake warehouse:build_htpasswd RAILS_ENV=production CONFIG=/home/demo/repositories/passwd

Now check the passwd file and ensure that it is written correctly with the [users] header and that your username and password appear:

cat ~/repositories/passwd
...
[users]
admin:password

All together now

Sweet! Warehouse can now dynamically write our authz and passwd files in a format that svnserve understands. This means svnserve is “receiving” instructions from Warehouse on how to behave and is securing your repositories as needed.

The final step is to tell Warehouse to execute that htpasswd command when users are modified. Go back into the Settings of the Admin tab and add the command:

rake warehouse:build_htpasswd RAILS_ENV=production CONFIG=/home/demo/repositories/passwd

to the “Shell command to run when someone’s password is updated.” option. From now on, when you add or update a user, the passwd file will be changed accordingly.

Finale

Phew! That was some decent work up there. But it is worth it. Your Subversion slice is running smoothly with no user/repository restrictions. You have about 8 GB of usable space for your content which is more than any of the SVN hosts out there provide. And with bandwidth cheaper than ever, you shouldn’t break more than $15 a month.

In general, this system covers the needs of the majority of users out there, but for the rest there are a couple of tweaks that might be helpful. In future parts, I will detail how to switch from Nginx to Apache and serve SVN through mod_svn which will increase our security options. There’s also a few other Warehouse tricks that might be helpful to some users. Stay in tune!

The typical implementation uses standard thumbnails linked to their full-sized image file in a way that if Javascript is turned off you can still click and get to the image. This is great for accessibility, but that also means that these Lightbox-enabled images look and feel like regular links. Because of this, the expected behavior when a user command+clicks (or control+clicks in Windows) is to have the link open in a new tab. However, the browsers don’t have a special click event for these shortcut keys so when the regular click event fires, the Lightbox uses it to activate its own features.

This breaks default expected behavior so it should be fixed. Since there is no built-in way to detect keys held during a click event, I’ve come up with a simple MooTools script that detects if a key is held down when a user clicks on an element. We basically set flags for the modifier type keys which are set when the user presses one of the keys. Then we create a custom event that can detect if any of the modifier keys are set. Here’s the code:

(function() {
	var keys = new Hash({ 16: false, 18: false });  // Shift and Option/Alt keys
	if (Browser.Platform.win) { keys[17] = false; } // Control key
	if (Browser.Platform.mac) { keys[91] = false; } // Command Key

	window.addEvent('domready', function() {
		$(document.body).addEvents({
			'keydown': function(e) {
				if (keys.has(e.code)) { keys[e.code] = true; }
			},
			'keyup':   function(e) {
				if (keys.has(e.code)) { keys[e.code] = false; }
			}
		})
	});

	Element.Events.cleanclick = {
		base: 'click',
		condition: function(e) { return !keys.hasValue(true) }
	}
})();

We can then use this new event instead of the regular click event to ensure our Lightbox only opens when a “clean” click is performed, i. e. a click without modifier keys held down. Here’s an example.

$$('a.lightbox').addEvent('cleanclick', function() {
	// openLightbox();
});

By default, anonymous users can only read from our repository. Since we haven’t setup a login mechanism for svnserve, we are treated as anonymous users so we can’t check in any files yet. Let’s fix this. We will create a single svnserve.conf file and make symbolic links to it from each of our repositories’ conf directories. User and directory access will be set with global password-db and the authz-db files rather than by tweaking each individual svnserve.conf (nightmare!).

The best part of this setup, we can coax Warehouse app to maintain these files for us and we can just do access rights from their interface.

svnserve.conf file

Let’s create the svnserve.conf file:

cd ~/repositories
nano svnserve.conf

Use these settings:

[general]
anon-access = none
auth-access = write
password-db = /home/demo/repositories/passwd
#authz-db    = /home/demo/repositories/authz
realm       = Example Repository

As you can see, we have disabled anonymous access with the anon-access option. You could change this if all your repos will be public but I find it better to deny first and allow on a case by case basis. For now, I commented out the authz-db file so that we don’t have to manage it manually (nightmare!). Once Warehouse is in the loop, it will take care of this file for us.

passwd file

Now create the passwd file:

nano passwd

And add your user account. The format is one username:password entry per line. Here’s mine:

[users]
admin:password

authz file

Next is the authz file. We’ll create it but leave it blank for now:

touch authz

Configure the repositories

Finally, let’s make our repositories use the newly created svnserve.conf file by creating symbolic links as follows:

ln -fs /home/demo/repositories/svnserve.conf project1/conf
ln -fs /home/demo/repositories/svnserve.conf project2/conf

Make sure they were created correctly with the following:

ls -l project1/conf
...
total 8
-rw-rw-r-- 1 demo demo 684 Sep 25 20:34 authz
-rw-rw-r-- 1 demo demo 309 Sep 25 20:34 passwd
lrwxrwxrwx 1 demo demo  37 Sep 25 22:16 svnserve.conf -> /home/demo/repositories/svnserve.conf

Perfect. We now have a single svnserve.conf file with which to manage repository access. Be sure to do this for any future repositories you create or they won’t follow the global rules we have set up.

Test out your account

Finally, to make sure everything is working correctly, let’s check out a copy of one of your repositories.

svn co --username admin svn://code.example.com/project1
...
Authentication realm: <svn://code.example.com:3690> Example Repository
Password for 'admin':
A    project1/trunk
A    project1/trunk/project1.txt
A    project1/trunk/newfile1.txt
A    project1/branches
A    project1/tags
Checked out revision 3.

Good, svnserve made us authenticate so no anonymous checkouts. Now let’s create a file and try to commit it. First create the file:

cd project1/trunk
touch commitTest.txt
svn add commitTest.txt
...
A         commitTest.txt

Now let’s do a commit:

svn commit -m "authentication test commit"
...
Adding         trunk/commitTest.txt
Transmitting file data .
Committed revision 4.

Looks good!

Warehouse configuration

First step is to decide if you want urls to your repos to be done with subdomains or subfolders. By default, Warehouse serves your repos from reponame.code.example.com. I personally like this, but I also like Disco music so I know to not trust my instincts. DNS can be tough for some people to edit so I’ll just use subfolders for this guide. If you like the subdomain style you can skip these steps.

Enable subdirectories

The right way to do this is to set the USEREPOPATHS=1 environment variable, but I can’t figure out how to do this with Nginx/Thin so let’s go with plan B and edit the environment.rb file instead. If anyone can enlighten me on how to set environment variables like this, I will update the guide. Anyway, let’s enable subdirectory access. From the warehouse directory, run:

nano config/environment.rb

Find the line:

#USE_REPO_PATHS = true

and uncomment it:

USE_REPO_PATHS = true

Now restart your Thin cluster:

sudo /etc/init.d/thin restart

Login to Warehouse

Re-visit your webpage (http://code.example.com/) and set up the first repo and user as follows. Note that the username and passwords you use here will later be synced up for svnserve to use. You probably want to use the same data you used when making the passwd file. Here’s my install page filled out:

You will now see this page where you can just tell Warehouse to syncronize the first changeset:

And now you will be taken to your first repo in Warehouse where you should be able to see the files we checked in earlier:

That’s it! Warehouse is now linked to your repository. Take some time to play around and explore. Be sure to check out the guides at Warehouseapp.com to get a feel for how the system works.

Next Steps

Subversion is officially ready to roll. It has basic authentication set up and we can now commit and check out files as needed from it. Warehouse was also initialized and it works on it’s own for now. Come back once you’re done playing around for the next article where we will configure some hooks to keep our svnserve configuration up-to-date and to automatically synchronize change-sets to Warehouse.

Create Warehouse DB

The first step is to create the MySQL databases which will house our Warehouse install. Login to mysql and execute the following commands:

mysql> CREATE DATABASE warehouse;
Query OK, 1 row affected (0.04 sec)

mysql> CREATE DATABASE warehouse_test;
Query OK, 1 row affected (0.00 sec)

Create Warehouse User

Next we will create a MySQL user specifically for Warehouse. By limiting the user’s access we can keep our MySQL database more secure as a compromise of this username and password will only give access to the Warehouse DB. Be sure to replace some_pass with a password of your choice:

mysql> CREATE USER 'warehouse'@'localhost' IDENTIFIED BY 'some_pass';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON warehouse.* TO 'warehouse'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON warehouse_test.* TO 'warehouse'@'localhost';
Query OK, 0 rows affected (0.00 sec)

Create the web root

Now let’s create a web root in our home folder where Warehouse will live:

mkdir /home/demo/public_html

Install Ruby Subversion bindings

Before Warehouse can run, we need to install the Ruby Subversion bindings which, as the name suggests, lets Ruby interact with your SVN repo. I’ve never been able to get them installed by following their guide but luckily we can just use yum to install the necessary components:

sudo yum install subversion-ruby

Now fire up IRB and let’s make sure it works:

irb
...
irb(main):001:0> require 'svn/core'
=> true

Download Warehouse

Our system is finally ready for Warehouse. To download it, we simply clone Warehouse via git by doing the following:

cd /home/demo/public_html
git clone git://github.com/entp/warehouse.git

Bootstrap Warehouse

Now tell Warehouse to initialize itself by running the following command and follow the instructions presented on screen. You might run into a couple of “errors” I’ve detailed below but don’t worry about them for now, they won’t stop Warehouse from running.

cd ~/public_html/warehouse
rake warehouse:bootstrap
...

Now it's time for Step 3: Load the database schema.  All of your data will be overwritten. Are you sure you wish to continue? [y/n]
y

mkdir -p /home/demo/public_html/warehouse/log
!! No Ultraviolet gem found, defaulting to javascript syntax highlighting.  Do not be afraid.
!! Error loading plugins: Mysql::Error: Table 'warehouse.plugins' doesn't exist: SELECT * FROM `plugins`   WHERE (name IN ('photo_gallery'))
!! Make sure the database was created successfully and migrated.
...

Warehouse v1.1.6 is ready to roll.
Okay, thanks for bootstrapping!  I know I felt some chemistry here, did you?
Now, start the application with 'script/server' and visit http://mydomain.com/ to start the installation process.

Sweet, we are ready to roll.

Configuring Thin

Create configuration file

cd ~/public_html/warehouse
sudo thin install
...
sudo thin config -C /etc/thin/warehouse.yml -c /home/demo/public_html/warehouse/  --servers 3 -e production

Start Thin

sudo /etc/init.d/thin start
...
[start] /etc/thin/warehouse.yml ...
Starting server on 0.0.0.0:3000 ...
!! Ruby 1.8.5 is not secure please install cgi_multipart_eof_fix:
   gem install cgi_multipart_eof_fix
Starting server on 0.0.0.0:3001 ...
!! Ruby 1.8.5 is not secure please install cgi_multipart_eof_fix:
   gem install cgi_multipart_eof_fix

Oops, install cgimultiparteof_fix

sudo gem install cgi_multipart_eof_fix

Start Thin again

sudo /etc/init.d/thin stop
...
sudo /etc/init.d/thin start
...
[start] /etc/thin/warehouse.yml ...
Starting server on 0.0.0.0:3000 ...
** Ruby version is not up-to-date; loading cgi_multipart_eof_fix
Starting server on 0.0.0.0:3001 ...
** Ruby version is not up-to-date; loading cgi_multipart_eof_fix

Optimize Thin

Let’s check our memory footprint:

Yikes! Our memory usage is close to our 256MB limit and we are starting to page in/out of the swap space. Looks like three Thin servers is too much for our 256 MB slice. Let’s fix this. Stop the Thin cluster:

sudo /etc/init.d/thin stop

Edit the Thin configuration file to deploy only two servers:

sudo nano /etc/thin/warehouse.yml

Change the servers option From:

servers: 3

To:

servers: 2

Restart the Thin cluster:

sudo /etc/init.d/thin start

Note: Be sure to stop thin BEFORE changing the amount of servers or you will end up with stray servers that don’t get shut down.

Check memory usage again:

Perfect, memory usage is now under 200 MB. Now, while it seems that the swap is still in use, it is actually the remains of what got paged there from our overload. It is not currently being paged in and out of. This is OK!

Configure Nginx

Proxy requests to Thin

Open up the virual hosts configuration file:

sudo nano /etc/nginx/conf.d/virtual.conf

and change the file contents to:

upstream domain1 {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    }

server {
    listen   80;
    server_name code.example.com;

    access_log /home/demo/public_html/warehouse/log/access.log;
    error_log /home/demo/public_html/warehouse/log/error.log;

    root   /home/demo/public_html/warehouse/public/;
    index  index.html;

    location / {
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect false;

        if (-f $request_filename/index.html) {
            rewrite (.*) $1/index.html break;
        }

        if (-f $request_filename.html) {
            rewrite (.*) $1.html break;
        }

        if (!-f $request_filename) {
            proxy_pass http://domain1;
            break;
        }
    }
}

This setup proxies all non-static requests (E.g. files that don’t exist on the filesystem in the public folder) to our Thin cluster.

Restart Nginx to apply the changes. I’ve heard that there’s some issues with the restart command so it doesn’t hurt to just start and stop the server:

sudo /etc/init.d/nginx stop
...
sudo /etc/init.d/nginx start

Navigate

Now cross your fingers and navigate to your server to view the Warehouse app:

http://code.example.com/

Nice!

Believe it or not, we now have our Subversion system up and running. We have svnserve listening in the background to check our code in/out while a web-facing Warehouse allows us to browse our code in our favorite Browser. Warehouse is running off a MySQL database backend and powered by a small Thin cluster in a proxy setup with Nginx. All of this on a small 256 MB slice which costs about $10 a month.

Alright, well let’s not get over excited. There’s still plenty of work to do. We can’t actually do much with Warehouse yet! In the next article, we will configure Warehouse to actually interface with our SVN repositories for web access and even user management and access control.

I’ll continue assuming you know how to do most of the stuff detailed in those guides. Specifically, we will deploy a svnserve instance listening on the default SVN port which will serve multiple repositories (not multiple projects) from a repository container in your home folder.

Install Subversion (and git!)

At this point, Subversion should already be installed on your system. If it’s not, this will take care of it:

sudo yum install subversion

Now while this tutorial might be about Subversion, Warehouse is hosted at GitHub and the easiest way to download it is via git so let’s install that right now too. Git lives under the EPEL repository we installed Nginx from so this simple command should do:

sudo yum install git

Create your repositories

Let’s begin by creating the folder to hold all of our repositories. We will also create a couple of test projects to get started. I will use the multiple repository type of layout where each project has its own repository. However, if you prefer something different, I’m sure you could easily adapt my guide to it.

From your home folder, run the following commands:

mkdir repositories
...
svnadmin create repositories/project1
svnadmin create repositories/project2

Create the recommended Subversion layout

Now let’s create a template folder which we can use to create the standard repo layout in newly created repos:

mkdir -p repositories/svn_default/{trunk,branches,tags}

Import the default layout into our test repos:

svn import /home/demo/repositories/svn_default file:///home/demo/repositories/project1 -m "initial import"
...
svn import /home/demo/repositories/svn_default file:///home/demo/repositories/project2 -m "initial import"

Create some projects

Next create some dummy projects and import them into the repositories:

mkdir project1
touch project1/project1.txt
...
svn import /home/demo/project1 file:///home/demo/repositories/project1/trunk -m "app import"

mkdir project2
touch project2/project2.txt
...
svn import /home/demo/project2 file:///home/demo/repositories/project2/trunk -m "app import"

We now have two separate repositories to play with.

Clean up

Delete the original project folders as they are no longer needed

rm -rf project*

Initialize svnserve

Let’s setup svnserve to serve our repositories now. Be sure to read the Introduction to svnserve guide first and follow the instructions on opening up the firewall for svnserve access on port 3690. Now start svnserve with the following command:

svnserve -d -r /home/demo/repositories/

Autostart svnserve

To make svnserve start automatically, add the following to your crontab:

crontab -e

@reboot svnserve -d -r /home/demo/repository

Test it

Let’s check out one of our test projects on our computer and verify it is working correctly. On your local computer, run:

svn co svn://code.example.com/project1
...
A    project1/trunk
A    project1/trunk/project1.txt
A    project1/branches
A    project1/tags
Checked out revision 2.

Everything looks good! We have our trunk/branch/tag structure and the file we checked in earlier is in there.

Security

The default svnserve configuration files allow for anonymous read access and authenticated write access. This might work for you but I’d like to secure the install a bit. However, I’ll hold off on that until we finish setting up Warehouse which we will use to secure svnserve.

It is also important to note that svnserve stores passwords on the server in a plain-text. This is not as bad as it sounds as authentication is done using the CRAM-MD5 mechanism so the passwords are never sent in the clear. So unless someone has physical access to the server, your passwords are safe. Of course, this might not be enough security for some users so a future upgrade will be to move to an Apache HTTP svn server which allows you to store passwords in a hashed format. But for now, the standard svnserve configuration will serve us well.

End Notes

We have now finished initializing our repository home. Even without Warehouse, your server is fully functional as a simple SVN server. In the next part we will get Warehouse installed to make managing simpler to and to provide a front-end interface for our code repositories.