Showing posts with label Subversion. Show all posts
Showing posts with label Subversion. Show all posts

How to install a specific version of a Debian package using apt-get

At work we use a backported version of Subversion as the stable package is 1.1.4 and I wanted to install the latest one we could get a package for which was version 1.3.2. Along with the backported Subversion package is a package that contains a number of useful hook scripts called subversion-tools.

When I did an apt-get install subversion-tools Debian wanted to install the 1.1.4 stable release not the 1.3.2 backported release. By doing an apt-cache show subversion-tools I was able to see the two available packages.

These are the steps I went through to install the backported version of subversion-tools, although these steps will work when installing any specific version of a Debian package.

Before you install a specific version of a package you need it's complete version.
This will be displayed when you run:
apt-cache showpkg <package name>

e.g.
apt-cache showpkg subversion-tools

> Package: subversion-tools
> Versions:
> 1.3.2-5~bpo1(/var/lib/dpkg/status)
> 1.1.4-2 (/var/lib/apt/lists/ftp.uk.debian.org_debian_dists_stable_main_binary-i386_Packages)


To install the specific version simply run run:
apt-get install <package name>=<version>

e.g.
apt-get install subversion-tools=1.3.2-5~bpo1

Technorati Tags: , , , , , , ,

Using cvs2svn to migrate your repository from CVS to Subversion

This week I migrated our codebase from CVS to Subversion!

I'd previously downloaded the Tigris cvs2svn migration tool onto my build server, read the documentation and performed a test run of the migration last week so I was pretty confident that I would have no problems.

These are the steps that I took to perform the migration:
Notes: For simplicity I'll assume that your CVS repository root is /cvs and your Subversion directory is /svn. The cvs2svn tool creates a new Subversion repository when you run the cvs2svn migration tool.

  • Log in to the build server (a Debian Linux box) as root

  • Change directory to /cvs and find the name of the module you want to migrate to a Subversion repository, I'll use the module old in my example.

  • Choose a suitable name for your new Subversion repository (it doesn't have to be the same name as the CVS module) I'll use new in my example.

  • Run the following command, (it's best to redirect it's output to a log file to so you can check for errors at the end):

    cvs2svn -s /svn/new /cvs/old
This operation may take a while if the CVS repository is large, our migrated repository took about 30 minutes to migrate and resulted in about 3,500 revisions. I had no problems in the area of branches or tags but this is one issue that has cropped up when I migrated another repository over. You need to use the --force-tag and --force-branch options to specify how to deal with any problematic tags.

I performed the migration as the root user to ensure that we wouldn't have any problems with file permissions when reading or writing files, but we now need to change the permissions of the newly created Subversion repository to ensure that Apache has access to the files:

chown -R www-data:www-data /svn/new

Your new repository will now be available in the same way that you access your other Subversion repositories, just remember to use your newly migrated repository name!

Technorati Tags: , , , , , ,

How to restore a deleted and committed directory in CVS

I had to put my CVS administrator hat on this morning when a colleague realised that yesterday he had managed to delete and commit a directory full of files by accident. We needed to roll-back the clock to yesterday afternoon so to speak but CVS doesn't really give you any handy tools to do this.

I first logged onto the CVS server and browsed to the relevant directory (on the server the directory and files are not deleted, just marked as so) and took a look inside one of the ,v text files to find the time when the commit happened (where the file's state changed from Exp to dead).

After a bit of searching I found a very clear set of instructions on the Ximbiot CVS Wiki that detailed how to restore a deleted directory.

I followed those instructions and brought the directory (and files) back to life again!

Technorati Tags: ,

Using Apache to display a list of available Subversion repositories

If you have setup Apache to be able to serve multiple Subversion repositories from one parent Subversion path then you are probably wondering if there is a way to display the list of repositories available in that parent directory.

By default Apache will give you a 403 permissions error reporting:

403 Forbidden

You don't have permission to access /parent-subversion-directory on this server.
To enable the repository listing you need to use the SVNListParentPath option (see "Listing available repositories in mod_dav_svn (server)" under "Enhancements and Bugfixes" in the 1.3 release notes) in the Apache virtual host setup.
Note: this will only work in Subversion 1.3 and higher.

Edit your Subversion Apache configuration file to add the SVNListParentPath On line, an example is given below:
# Subversion
<Location "/svn">
DAV svn
SVNParentPath /svn
SVNListParentPath On
SVNIndexXSLT "/svnindex.xsl"
</Location>
If you now visit http://some-website.com/svn you will see a page entitled "Collection of Repositories" with a listing of links pointing to each Subversion repository!

Technorati Tags: , , ,

How to switch your working copy when the Subversion repository URL has moved

If you followed my previous post on Supporting multiple Subversion (SVN) repositories with Apache you may have noticed that I moved the repositories from:

http://some-url/a
http://some-url/b


to:

http://some-url/svn/team-a
http://some-url/svn/team-b


If you had a working copy checked out of either of these Subversion repositories then you would have received an error when attempting an update due to the repository being moved since you checked out the code.

You need to update your working copy to point to the new repository but maintain any local changes that you might have made - my colleague Guy Francis pointed out that you use the svn switch command to do this.

Here is how you update your working copy's repository URL:

  • Change directory so that you are inside the working copy
  • Run svn switch --relocate http://some-url/a http://some-url/svn/team-a .
This will go through the whole directory structure updating the source URL to point to the new location, the --relocate option forces Subversion to just update the files locally no access to the remote repository is required.

Technorati Tags: , , ,

Supporting multiple Subversion (SVN) repositories with Apache

My previous posts about Subversion on Debian Linux (installing, configuring, backported packages) showed how I installed and configured my local repository that I use for my home projects. I also used these tutorials when installing Subversion at work.

After creating a couple of repositories for different teams (all within the base /svn directory) I noticed that my Apache configuration file was starting to look a little repetitive:

# Subversion - team A
<Location "/a">
DAV svn
SVNPath /svn/team-a
SVNIndexXSLT "/svnindex.xsl"
</Location>

# Subversion - team B
<Location "/b">
DAV svn
SVNPath /svn/team-b
SVNIndexXSLT "/svnindex.xsl"
</Location>
I plan on creating at least two more repositories for other teams and so this was repetition was starting to bother me. A colleague pointed out that SVNParentPath (scroll about 1/4 down) should be the solution.
I rewrote my conf file to be the following:
# Subversion
<Location "/svn">
DAV svn
SVNParentPath /svn
SVNIndexXSLT "/svnindex.xsl"
</Location>

Now any repositories that are created within the parent /svn directory will be available via http://some-url/svn/<repository name>, so my existing repository become:

http://some-url/svn/team-a
http://some-url/svn/team-b

Technorati Tags: , , ,

Problems with Trac and backported Subversion on Debian Linux

After installing the backported package of Subversion last week and importing a pre-existing codebase into it I decided that now was a good time to put Trac on the server.

Following my previously blogged Trac installation & configuration guides I was able to get Trac up and running fairly smoothly with one small problem: the "Browse Source" button was failing reporting some issue with "svn" being an unknown repository type.

After some searching and thinking I realised that this was most probably due to conflict between the newer backported version of Subversion and the older Python Subversion bindings libraries.

Here's how I resolved this issue:

apt-get remove python2.3-subversion
apt-get install python-subversion


Refreshed my browser and everything worked correctly!

Technorati Tags: , , , , ,

Installing Subversion 1.3.2 using Backports on Debian (Sarge) Linux

Following on from my previous posts about installing Subversion from source, here are some notes on how to do it using backported Debian packages.

Add the following lines to your sources.list file in /etc/apt:

# backports
deb http://www.backports.org/debian sarge-backports main contrib non-free


Update your Apt sources list:

apt-get update

Uninstall any old Subversion packages:

apt-get remove subversion
apt-get remove libsvn0


Install Subversion with 1.3.2 as a specific version (this causes the backported version to override the stable version):

apt-get install libsvn0=1.3.2-5~bpo1
apt-get install subversion=1.3.2-5~bpo1


Check that the installed Subversion is the right one by using svn --version you should get something like:

svn, version 1.3.2 (r19776)
compiled Aug 12 2006, 12:05:49
...


Install the Apache2 Subversion modules:

apt-get install libapache2-svn=1.3.2-5~bpo1

Follow my instructions on Configuring Subversion (svn) on Linux (Debian Stable).

There you go!

Technorati Tags: , , , ,

Upgrading Subversion (svn) to 1.3.2 on Linux (Debian Stable)

I upgraded my Subversion repository tonight from 1.2.1 to 1.3.2 and it was an absolute breeze!
I followed the Subversion installation instructions that I've blogged about before (using the newly downloaded 1.3.2) ignoring the bit about installing Apache.

Ran through the usual Linux make, make install stuff, restarted Apache and accessed the repository browser webpage which displayed the updated version number at the bottom.

Couldn't have been simpler!

Technorati Tags: , , ,

Creating a dummy Debian package for Subversion (svn)

Since I've installed Subversion, I've been looking around for a good wiki and ticket management system so that I can get the whole 'development environment' setup on my home server.

I installed Wikipedia's MediaWiki at work, after our Instiki wiki came unstuck and left me with a whole load of nothing after it decided to stop writing archives to disk for about 5 weeks! MediaWiki is a little heavyweight for what I need, so I started to look around. I noticed on the Ruby on Rails website that they had a pretty simple ticket system, and after some investigation it turned out to the the open source Python-based Trac.

Trac also has a rather pretty Subversion repository browser so it seemed perfect for the small home projects that I want to develop.

I went to 'apt-get' Trac on my Debian Stable server, only to find that it wanted to install Subversion as a dependency even though I had a later version installed from source.

The Debian package management system works great so long as you don't install any applications from source, if you do it doesn't know they are installed and so will try to install over the top of your newer version.

What you need to do is create a 'dummy package' to fool the Debian package management system into thinking that it's installed a valid package. Here's how I made a Subversion package for my latest 'built from source' version 1.2.1 of Subversion.

First you need install the equivs package, this provides all the tools to be able to build Debian packages that apt-get & dpkg can understand and install.

apt-get install equivs

Now that equivs is installed, you need to generate the templates that are used to build the package. Run equivs-control and pass in the name of the package that you want to create. In my case I wanted to emulate the Subversion package that Trac wanted to install which was named 'subversion'.

equivs-control subversion

This creates a 'subversion' file in the directory that you ran the equivs-control command from. Edit this file as follows:

* Leave the top three lines:

Section: misc
Priority: optional
Standards-Version: 3.5.10

* Change the following lines: (note: the Subversion I installed was 1.2.1, hence the "Version: 1.2.1-1" value)

Package: subversion
Version: 1.2.1-1
Maintainer: Andrew Beacock <andrew@andrewbeacock.com>
Architecture: all
Description: A dummy Subversion package to fool Debian's package management system into thinking that the 'built from source' version is an official Debian package.

* Remove all these lines:

Pre-Depends: <packages>
Depends: <packages>
Recommends: <packages>
Suggests: <package>
Provides: <(virtual)package>
Copyright: <copyright file; defaults to GPL2>
Changelog: <changelog file; defaults to a generic changelog>
Readme: <README.Debian file; defaults to a generic one>
Extra-Files: <additional files for the doc directory, commaseperated>

Save the file, quit back to the console and then run the equivs-build command to build the package.

equivs-build subversion

As long as you've done everything right, it will start to generate all the install scripts that are required by Debian packages, and ends up creating an equivs directory (that can be safely deleted) and the package itself - subversion_1.2.1-1_all.deb.

Now install this package using dpkg as you have it locally and apt-get would get the wrong version from the internet.

dpkg -i subversion_1.2.1-1_all.deb

You now have Subversion registered in Debian's package management system. To prove it, run dpkg -l subversion, there should be "ii" to the left of the listing for "subversion". This means that you can now install Trac without it stomping over your existing 'latest version' of Subversion.

A future post will document the steps involved to build Trac from source, but using the Debian package management system to install all the dependant components...

Technorati Tags: , , , ,

Configuring Subversion (svn) on Linux (Debian Stable)

My last post documented how to install Subversion. This post will cover the resulting configuration of Apache, plus the creation of the initial repository.

When you install Subversion, it adds two LoadModule lines to /etc/apache2/httpd.conf. This is not wanted as the Debian version of Apache2 installs things slightly differently from the default Apache (httpd.conf is not used, all this configuration now lives in apache2.conf, plus the loading of modules is done differently). edit /etc/apache2/httpd.conf and remove the 2 uncommented LoadModule lines.

Debian loads modules a little differently that the default Apache2. It lists the available modules as individual configuration files within a mods-available directory, then enables these by linking to them from a mods-enabled directory.

We need to create the two required module configuration files that are required by Subversion (we just removed them from /etc/apache2/httpd.conf!):

cd /etc/apache2/mods-available
echo "LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so" > dav_svn.load
echo "LoadModule authz_svn_module /usr/lib/apache2/modules/mod_authz_svn.so" > authz_svn.load


Now we need to enable them so that Apache will load them when it restarts:

cd ../mods-enabled
ln -s ../mods-available/dav.load
ln -s ../mods-available/dav_svn.load


That's the modules configured, now we need to create the Subversion virtual host entry that will point to our Subversion repository. Again, Debian does things a little different with virtual hosts, it has them listed as separate virtual host configuration files in sites-available and then enables them in sites-enabled:

cd /etc/apache2/sites-available

Due to Blogger being a pain when it comes to trying to post details containing lots of <'s and >'s, I'm including a link to an almost-copy of my Subversion virtual host configuration file. As you can see, it points the WebDAV & Subversion modules at /var/svn which will be the root of our repository, and uses Apache's htpasswd authentication to validate access.

Now we need to make the Subversion site available to Apache:

cd ../sites-enabled
ln -s ../sites-available/svn


Ok, that's Apache all done and dusted, now we just have to actually create the repository and then we are done.

The repository must be 'owned' by the same user that Apache runs as, otherwise read/write access may be blocked and all sorts of strange problems can occur, Debian runs Apache as user www-data by default:

mkdir /var/svn
chown www-data:www-data /var/svn


Now that the repository's root directory has been created, it's best to be the same user as Apache when creating the repository to ensure the files are created with the correct permissions:

su – www-data
svnadmin create /var/svn


That's the repository created, now we need to restart Apache to let the WebDAV & Subversion modules know that the repository is now available:

/etc/init.d/apache2 reload

If you now point your browser at http://svn.yourdomain.com you should see a web view of your new repository...what's that? It's asking for a username and password? Oh yes, we need to create any required users via the Apache htpasswd utility:

cd /etc/apache2
htpasswd -c svn.htpasswd your_username


Ok, try that URL again, you should be able to login and see a rather basic view of an empty Subversion repository. There is a slightly nicer skin that can be applied to Subversion to make the repository view cleaner, it's tucked away in the /usr/local/src/subversion-1.2.1/tools/xslt directory. These XSL and CSS files need to be added to the virtual host's document root, but as you may have noticed the DocumentRoot is the root of the Subversion repository. This means that you just have to import the two files into Subversion for the changes to take effect:

cd /usr/local/src/subversion-1.2.1/tools/xslt
svn import svnindex.xsl http://svn.yourdomain.com/svnindex.xsl -m "Improved web interface."
svn import svnindex.css http://svn.yourdomain.com/svnindex.css -m "Improved web interface."


Now revisit that URL again, and it should be a slightly nicer view of the repository, now with two files in it, svnindex.xsl and svnindex.css.

That's it, the repository is fully available to any user that you have created an htpasswd entry for in /etc/apache2/svn.htpasswd and who has a suitable Subversion client (TortoiseSVN and RapidSVN are two that I have used).

For full documentation on how to really use Subversion, please take a look at the O'Reilly Version Control with Subversion online book or buy the rather excellent book Pragmatic Version Control Using Subversion by Mike Mason.

Please let me know if you found this post (and the last one on how to install Subversion) useful, if so I might start to blog about Subversion even more...

UPDATE: I've moved some files around on my server, I've not changed any of the content of this post.

Technorati Tags: , , , ,

Installing Subversion (svn) on Linux (Debian Stable)

This post details my recent install of Subversion 1.2.1 on Debian Stable. The Debian packaged version of Subversion is currently only 1.1.4, but I wanted to install the latest version as it supports full WebDAV autoversioning & has the FSFS repository back end as the default.

I wanted to access Subversion via the WebDAV protocol, this requires Apache2. As Debian Stable only recently included the apache2 package, I had to update to that version first.

Note: all these commands were run as the root user.

Install Apache2:

apt-get install apache2

That installs the web server and all the required packages, it does not start Apache by default, you need to edit /etc/default/apache2 and change NO_START to 0, then run /etc/init.d/apache2 start to get the basic web server running.

When you build Subversion from source, it requires the apxs2 tool to be able to build and install the Subversion extension modules. This is hidden away in the apache2-threaded-dev package, it's not available in any other package:

apt-get install apache2-threaded-dev

Now we need to download, build and install Subversion. Download Subversion 1.2.1 and save it in /usr/local/src

Unpack Subversion:

tar zxvf subversion-1.2.1.tar.gz
cd subversion-1.2.1

We now need to ensure that all build dependencies are taken care of, plus let the build scripts know where the apxs2 tool is located (it's in a non-standard place with Debian):

./configure --with-apxs=/usr/bin/apxs2

Build Subversion:

make

Run the unit tests to ensure that the built version is a valid release (note: this can take quite a while - well at least it does on my poor Celeron Linux server!):

make check

Install the Subversion binaries and libraries to the correct places:

make install

OK, that's Subversion installed, but it's not available yet, we still need to config access to it via Apache, and create the initial code repository. Please see my next post on how to do this...

Technorati Tags: , , ,