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
Debian loads modules a little differently that the default Apache2. It lists the available modules as individual configuration files within a
We need to create the two required module configuration files that are required by Subversion (we just removed them from
Now we need to enable them so that Apache will load them when it restarts:
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
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
Now we need to make the Subversion site available to Apache:
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
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:
That's the repository created, now we need to restart Apache to let the WebDAV & Subversion modules know that the repository is now available:
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:
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
Now revisit that URL again, and it should be a slightly nicer view of the repository, now with two files in it,
That's it, the repository is fully available to any user that you have created an htpasswd entry for in
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: Subversion, Debian, Apache, Mike Mason, Andrew Beacock
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.loadNow 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.loadThat'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-availableDue 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/svnOk, 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/svnNow 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/svnThat'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 reloadIf 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_usernameOk, 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: Subversion, Debian, Apache, Mike Mason, Andrew Beacock
Comments
Everything still works fine with Subversion 1.3.1.
I'll have to get my repository upgraded soon!
grep: /etc/apache2/sites-enabled/svn: no such file or directory
Any ideas?
Where is the "grep: " bit of the error coming from?
Your guide was possible to copy-paste through besides this point.
I run up to the same problem, but solved it quickly, so I hope I'm in time to help the other anonymous.
And, thanks a lot for your guide, I got Subversion up and running very quickly with your help!
--
arttu dot manninen at protie dot fi
your guide is great.
the only problem I encounter is thatI can't access the svn web interface.
This is the content of my /etc/apache2/sites-available/svn file:
(VirtualHost *)
ServerName svn.localhost.localdomain
ServerAlias svn.localhost
DocumentRoot /var/svn
ServerAdmin me@server.com
ErrorLog /var/log/apache2/svn-error.log
CustomLog /var/log/apache2/svn-access.log combined
(Location /)
DAV svn
SVNPath /var/svn
SVNIndexXSLT "/svnindex.xsl"
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/svn.htpasswd
Require valid-user
(/Location)
(/VirtualHost)
The apacpache server is running, so is SVN and DAV but I can't login to the web interface??
Have you made the link from sites-enabled pointing to the svn file in sites-available?
What are you getting from Apache when you try to access your repository from a browser?
Is your repository running at svn.localhost and is this hostname in your /etc/hosts file?
Is your repository at /var/svn?
Does apache report any problems when you perform a full restart?
i've got it working now.
I just changed SVNPath to SVNParentPath end deleted the domain name, I just work with the ip now.
seems like i need to run a local domain server (bind) to accomplish this.
thx for your help and your great guide!
Thanks for posting and appreciate your work !
Thanks,
Raghu
in above link, i haven't found the respective URL location, i mean there was no data available on that location........ so please let me response as soon as possible
Sorry about that I've moved my hosted files around and forgot to update this blog post!
SVNIndexXSLT /svnindex.xsl
Mozilla Firefox gives me the following error: "An XSLT stylesheet does not have an XML mimetype http://svn.example.com/svnindex.xsl" as the .xsl and .css files are pulled from the SVN repository. Putting these files outside the SVN repository (on another vhost or in another Alias-ed directory solved the problem (svnindex.xsl is served with text/xslt now). I guess there are no such problems on IE due to its brain-dead magic filetype guessing.
I'll check my Apache configuration to see if I can find any clues, but if you find a solution then please post a comment with your findings.
I've found a solution or three to this problem. mod_mime has an option called ModMimeUsePathInfo http://httpd.apache.org/docs/2.2/mod/mod_mime.html#modmimeusepathinfo which basically as far as I got it checks the full path of the request and sets the mime-type appropriately. This config option is by default set to 'off', so mod_mime doesn't consider the full path of the request, but gets only the part that is outside dav_svn's scope (i.e. the part outside the virtual tree, in you case it's '/' in my case it's '/svn/') and the request (and the mime-type returned) is then handled by mod_dav_svn. So setting this directive to on makes apache return mime-type out of its mime-type config instead of letting mod_dav_svn decide on it. This works for me and now accessing http://devel.server.com/svn/svnindex.xsl returns text/xslt instead of text/plain and Mozilla doesn't barf.
Another solution is setting svn:mime-type property inside your SVN repository, which will force mod_dav_svn to return the property value instead ot text/plain. http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.mime-type
Another possibility is automapping:
http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.auto
You probably have one of these two set up in your SVN repo, so maybe that's the reason you don't have the same problem as I do.
Now honestly I don't have any idea of the impact of any of these two solutions as I am just a system administrator of the server in question. And since I'm not a programmer and am not using this repository I've got no idea of how this would impact usability.
Hope this helps.
Hristo
Have you got your own blog? If not you should as you are extremely good at explaining things is a clear easy to understand manner! :)
Thanks for the solutions, I'm scratching my head now wondering if I set the mime-types properties direct or let SVN manage them for me.
It must have done it automatically as otherwise I would have blogged about it in the setup instructions.
Anyway thanks again for all the great information!
One more thing. mod_dav_svn has an option "SVNAutoversioning on" which, when combined with "ModMimeUsePathInfo on" might set svn:mime-type property based on mod_mime's logic on import.
http://svnbook.red-bean.com/en/1.4/
svn.ref.mod_dav_svn.conf.html
(breaking the urls since blogger truncates them. Doh! don't you love it?)
Here are the three urls form my last comment:
http://httpd.apache.org/docs/2.2/mod/
mod_mime.html#modmimeusepathinfo
http://svnbook.red-bean.com/en/1.2/
svn.advanced.props.html#svn.advanced.props.special.mime-type
http://svnbook.red-bean.com/en/1.2/
svn.advanced.props.html#svn.advanced.props.auto
I'll take a quick look in the mods-enabled to see if I have anything in there...
#
# TypesConfig points to the file containing the list of mappings from
# filename extension to MIME-type.
#
TypesConfig /etc/mime.types
Within /etc/mime.types I have entries for CSS and XSL:
$ grep css mime.types
text/css css
$ grep xsl mime.types
application/xml xml xsl
So apache is using this file to determine the correct mime type to return in the HTTP header response.
Hope this helps!
thank you for your kind words! For me it's a way to give something back to the whole FOSS community. I'm glad that my explanations are clear and understandable even though English is not my native language. I must commend you on your howto as well. It's very precise and clear. I've had no problems following it. And, as you'll see in a second it's working perfectly well, despite my problems.
Here it goes: mod_mime is set up the same way on my server, it just doesn't kick in with my setup. Checking if mod_mime and /etc/mime.types is set up correctly was the first thing I checked yesterday. I even tried adding "AddType application/xml xsl" to my <Location> config but it simply didn't make any difference.
But I think I've finally found the culprit of the problem. It stems from the fact that your repository is set up as '/' on your server. In this case (and this is my wild guess after reading the doc of ModMimeUsePathInfo) mod_mime does it's job and gives the correct definition from /etc/mime.types. In my case though, my SVN repo is rooted in '/svn/' (http://devel.server.com/svn/) in which case, apparently, mod_mime doesn't kick in and leaves the mime-type determination to dav_svn.
I've set up another vhost svn.server.com with SVN rooted at '/' and it works the same way your setup does.
Anyway, mod_mime is one of the fundamental modules of apache, without it a lot of stuff wouldn't work as expected on standarts compliant and sane browsers (everything except IE? ;-)).
This entry starts looking like an IRC chat, isn't it? ;-))
Did you find out a solution?
Alexey
<Location /repos>
DAV svn
SVNPath /path/to/repos
ModMimeUsePathInfo On
</Location>
Firstly thank you for creating a wonderful post on SVN. This has by far been the best tutorial on SVN.
I have installed SVN successfully and can also browse the repository using the browser... but the issue is that I am unable to import a file into the repository.
I get this error:
Error: Error while performing action: Can't open activity db. No such file or directory
Can you please help.
Would like to thank you again for creating a brilliant post.
Regards,
SuniilBhatia
* What tools/programs are you using to try and import or add the file? Standard SVN client via commandline or some other tool?
* When you run the import command are you doing it as the same user that installed subversion or as a normal user?
* Check the permissions of the installation around the area of the database files to ensure that they are accessible from your users.
* Have you installed the repository on a shared or mounted drive as this is not recommended: http://svnbook.red-bean.com/en/1.1/ch05s02.html
Hope some or all of this helps! Keep me posted...
Thank you for helping out.
Ans1: I use the CLI and TortoiseSVN for import. For CLI I use this syntax:
/usr/local/subversion/bin/svn import svnindex.xsl http://svn-server.domainname.com/svnindex.xsl -m "Improved web interface."
Ans2: I run it as root. But when I execute the same command from TortoiseSVN, I am logged in as the SVN user that I created in the htpasswd file.
Ans3: I have tried this as well. I am able to open files using the user pbsvn. I have created a user and group by the name of pbsvn and also make apache run as this user and group. However when I run the command ps aux | grep "httpd" it gives me the following output. Dont know how is the first thread running as 'root'
root 25596 0.0 0.4 18896 8744 ? Ss 18:35 0:00 /usr/sbin/httpd
pbsvn 25599 0.0 0.2 19280 5584 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25600 0.0 0.2 19280 5476 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25601 0.0 0.2 19280 5516 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25602 0.0 0.2 19280 5576 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25603 0.0 0.2 19280 5556 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25604 0.0 0.2 19248 5508 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25605 0.0 0.2 19280 5460 ? S 18:35 0:00 /usr/sbin/httpd
pbsvn 25606 0.0 0.2 19280 5496 ? S 18:35 0:00 /usr/sbin/httpd
Ans4: I have installed the repository on a Virtual Machine. As regards mounted drive, can you please help me understand how I can go about checking that.
Thanks again!
Regards,
SuniilBhatia
Please check that all files and directories are owned by the same user or group that apache is running as, chown -R user:group *
Another thing to check is the WebDAV configuration to ensure that it really is looking in the correct place for the Subversion installation.
You mentioned virtual servers, do you have all of this running within one server or are you doing some cross-virtual server testing?
If all else fails try to add the files by placing them on the same host as the repos and adding them with the command line using a file:/// style URL: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.tour.importing.import
file-based URL
I think I have solved this issue. All I did was use SVNParentPath as I wanted to create many sub repositories. In addition to this I also created a folder by the name of 'dav' (with user and group as that which runs apache).
Here is my httpd.conf listing. Hope its useful for someone else.
(VirtualHost *)
ServerName svn-server.domainname.com
ServerAlias svn-server.domainname.com
DocumentRoot /var/www/html
ServerAdmin svn@youdomain.com
ErrorLog /var/log/apache2/svn-error.log
CustomLog /var/log/apache2/svn-access.log combined
(Location /svn)
DAV svn
SVNParentPath /var/svn
AuthType Basic
AuthName "Your Domain's Subversion Repository"
AuthUserFile /etc/apache2/svn.htpasswd
Require valid-user
(/Location)
(/VirtualHost)
Thanks again for all your help.
Regards,
SuniilBhatia
Thanks for posting your solution and glad to be of whatever help I was!
The issue was:
a. Location / configuration of the repository
b. dav folder was missing inside my repository, which once created resolved the issue of uploading files.
Regards,
SuniilBhatia
When checking in the from windows or linux - I get this strange error:
Can't convert
>> string from native encoding to 'UTF-8'
I have tried everything from setting locale to en, en_US, en_US.iso885915
Can you please help me out.
Regards,
Suniil
What is the locale of the server?
Thank you for a quick reply.
Here is the output of the 'locale' command:
LANG=en_US.iso885915
LC_CTYPE=en_US.iso885915
LC_NUMERIC=en_US.iso885915
LC_TIME=en_US.iso885915
LC_COLLATE=en_US.iso885915
LC_MONETARY=en_US.iso885915
LC_MESSAGES=en_US.iso885915
LC_PAPER=en_US.iso885915
LC_NAME=en_US.iso885915
LC_ADDRESS=en_US.iso885915
LC_TELEPHONE=en_US.iso885915
LC_MEASUREMENT=en_US.iso885915
LC_IDENTIFICATION=en_US.iso885915
LC_ALL=
Regards,
Suniil
However, none of them work.
We use TortoiseSVN on Windows Machine.
Regards,
Suniil
~Sunny