Codingmentor Developer's Forum

As you can see with my runconfigure.sh wrapper script for Subversion, I was very specific about which features I did and did not want in my Subversion installation. Because I knew exactly what I wanted, I could afford to do this, and it spared me from prerequisite hell.You can change the apache as you want.You cn chage it as /usr/local/apache opr apache 1.3

Once I saved runconfigure.sh, I ran it and installed Subversion:

First, I needed to ensure that the binary could find Subversion's shared libraries. On Linux, I did this by ensuring that /etc/ld.so.conf contained the directory /usr/local/lib. (The /etc/ld.so.conf layout is just a list of directories, one per line--a refreshingly simple syntax, in this age of XML.) If your copy of /etc/ld.so.conf is missing /usr/local/lib, add it, and then run ldconfig with no arguments. On Solaris, ensure that $LD_LIBRARY_PATH contains /usr/local/lib. If that directory is not present, add it in /etc/profile and export LD_LIBRARY_PATH so that all users automatically pick it up when they log in. Also, if you are on Solaris, change your current environment so that you have access to Subversion's libraries right away:

On any Linux/Unix system, be sure to add Subversion to your path. On my machine, I placed it first in the path, so that it would override any older Subversion that might be in /usr/bin:

On any Linux/Unix system, you may want to ensure that anyone who logs on to the system has Subversion in the path. Here's a nifty way I did that without having to open a text editor:

Creating the Repository

Next, I needed to create a Subversion repository. In real life, I actually used cvs2svn to port an entire CVS repository to Subversion; as long as you already have Python installed on your system, cvs2svn is fantastic. You may not have an existing repository to migrate, though, so here's how to create a sample repository and check in a one-file project:

Integrating Subversion with Apache

I wanted to use basic authentication to restrict access to my repository, so I created a .htpasswd file. What better location for this than the repository's configuration directory? Please note that for illustrative purposes, I used htpasswd's ability to accept passwords on the command line; you may want to make htpasswd prompt you for the passwords instead. I also used ridiculously insecure example passwords for illustrative purposes. Note how the first invocation of htpasswd used the -c switch to create the password file, whereas subsequent ones did not. Finally, if you don't mind having the passwords briefly shown in clear text, and you have to create a lot of users, consider making this a shell script that you can just run once and then delete when you are done:

One step I didn't want to forget was making the repository readable and writable by the user nobody, which Apache runs by default. (Forgetting this step would produce sorts of errors from Apache.)

Finally, I changed httpd.conf to let Apache know about my repository and the fact that only authorized users should read and write to it. I plan to use my Apache installation only for Subversion, so I made the Subversion repository the root of Apache's filesystem. In /usr/local/apache2/conf/httpd.conf, I made the line containing DocumentRoot look like:

Next, I added these lines to the end of /usr/local/apache2/conf/httpd.conf to let Apache know that /usr/local/svn_repository is a Subversion repository and that access uses SSL and basic authentication:

After those lines in /usr/local/apache2/conf/httpd.conf, I added the following mod_rewrite lines as a nice way to forward browsers from http to https:

Ensuring Apache Starts When the Server Does

Chances are your Linux/Unix installation shipped with Apache already installed. My Fedora Core system did, so I disabled it to keep it from interfering with my custom Apache, which wanted to use the same ports.

The method for disabling the automatic startup of Apache is different from system to system. Fedora Core uses a spiffy system utility called chkconfig to manage the starting and stopping of system services at various runlevels. I asked chkconfig what runlevels Apache was running at:

I told chkconfig not to run Apache at the three runlevels where it was on, and then I shut down Apache manually (as it was currently running).

At that point, I needed to put a different script in /etc/rc.d/init.d to start and stop my custom Apache. Fortunately, /usr/local/apache2/bin/apachectl is a shell script that already mostly follows the conventions of a Unix init script: it already takes start and stop as arguments. However, it uses the nonstandard startssl and stopssl to make Apache use SSL, so I had to do some editing.

First, I copied Apache's control script into Fedora Core's standard location for init scripts:

Next I borrowed, in altered form, the first few lines of Fedora Core's /etc/rc.d/init.d/httpd script and put them at the top of /etc/rc.d/init.d/apache_svn, so that Fedora Core's spiffy chkconfig program could use apache_svn. (Note that chkconfig's parameters in init scripts seem to be only comments, but they are more than that.) Here are the lines I added just below

to define the property SSL for all four targets captured by that stanza, as well as to give some feedback on the command line (though not as pretty as Fedora Core's scripts).

Next I told chkconfig to add apache_svn to its setup, and to make it active at runlevels 3, 4, and 5:

Then I started Apache using its new init script.

Testing the Connection

The moment of truth came when I got to test repository access from my web browser. I went to https://localhost/, accepted the cert, entered one of the sample usernames and passwords, and browsed my Subversion repository.

The command-line client worked too:

=======================================================