1) Installation:
The first thing to do is to install the packages I mentioned above. If you don’t have Apache installed already, it’ll go ahead and drag that down as well.
[root@lucifer ~]# yum install mod_dav_svn subversion
2) Configurations:
a) Apache:
…
b) Subversion’s Apache configs:
The next step is to setup some settings within Apache so Subversion and Apache play nice together. Get yourself to the example configuration file Subversion installed for you.
[root@lucifer ~] cd /etc/httpd/conf.d/
[root@lucifer ~] vim subversion.conf
# Make sure you uncomment the following if they are commented out
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
# Add the following to allow a basic authentication and point Apache to where the actual
# repository resides.
<Location /repos>
DAV svn
SVNPath /var/www/svn/repos
AuthType Basic
AuthName “Subversion repos”
AuthUserFile /etc/svn-auth-conf
Require valid-user
</Location>
The location is what Apache will pass in the URL bar. For instance: http://yourmachine/repos points to the SVNPath that you have specified. My examples are just that, so feel free to put things where you want. Make sure you save the file when you are finished editing.
Next we have to actually create the password file that you specified in the previous step. Initially you’ll use the -cm arguments. This creates the file and also encrypts the password with MD5. If you need to add users make sure you simply use the -m flag, and not the -c after the initial creation.
[root@lucifer ~] htpasswd -cm /etc/svn-auth-conf yourusername
New password:
Re-type new password:
Adding password for user yourusername
[root@lucifer ~] htpasswd -m /etc/svn-auth-conf anotherusername
New password:
Re-type new password:
Adding password for user anotherusername
c) Configure your repository
The next thing you need to do is to create the actual repository from which you will check in and out your files. This is simple to do with some of the included svn tools.
[root@lucifer ~] cd /var/www/ — Or wherever you placed your path above
[root@lucifer ~] mkdir svn
[root@lucifer ~] cd svn
[root@lucifer ~] svnadmin create repos
[root@lucifer ~] chown -R apache.apache repos
[root@lucifer ~] service httpd restart
Go test out whether or not you can access your repository from a web browser: http://yourmachine/repos. You should get a popup box asking for a username and password. If so, type in your credentials and you should be displayed with a Revision 0:/ page. If so, that’s it for setting up a repo. If you want multiple repos, check out the docs from the links provides above. This sets up one repository and shows you how to start using them. Speaking of, let’s move on to just that.
3) Using Subversion:
a) Layout Your Repo:
If all went well above, you’re now ready to start using the repository that you created. Subversions svn tool is the command line client that you will use to talk to the database. To see the use of the tool:
[root@lucifer ~] svn –help
The most common arguments you will most likely be using are: svn import, svn commit (ci), and svn checkout (co). With these you will initially import files into your repository with import, you’ll check them out to work on them with checkout, and you’ll commit the changes back into the database with commit. It’s pretty simple once you see them in use a few times.
Before I continue I’d like to explain about directory structure layouts. Almost all of the documentation talks about creating a certain layout for your directories. They specifically mention about making sure you have a branches, tags, and trunk underneath the root directory structure, where trunk holds all your files. For instance:
.
|– project1
| |– branches
| |– tags
| `– trunk
`– project2
|– branches
|– tags
`– trunk
The book explains why in a bit more detail, and I mainly don’t bother using this type of layout…because I’m not doing coding and maintaining “projects” per se. I’m mainly using it to store configuration files, and text items that aren’t as complex. Set things up for whatever works for you.
As an example, I’m going to just create some dummy directories and throw some files in them. This is from the actual SVN server. Play along.
[root@lucifer ~] cd /tmp
[root@lucifer ~] mkdir mytestproj
[root@lucifer ~] cd mytestproj
[root@lucifer ~] mkdir configurations options main
[root@lucifer ~] vim configurations/testconf1.cfg — Add whatever you want to these files.
[root@lucifer ~] vim options/testopts1.cfg
[root@lucifer ~] vim main/mainfile1.cfg
Keep in mind that you can layout anything anyway you’d like. Once you have the initial layout of what you want, let’s go ahead and import this up to Subversion.
b) Importing:
[root@lucifer ~] svn import /tmp/mytestproj/ file:///var/www/svn/repos/mytestproj -m “Initial repository layout for mytestproj”
Adding /tmp/mytestproj/main
Adding /tmp/mytestproj/main/mainfile1.cfg
Adding /tmp/mytestproj/configurations
Adding /tmp/mytestproj/configurations/testconf1.cfg
Adding /tmp/mytestproj/options
Adding /tmp/mytestproj/options/testopts1.cfg
c) Checking Out:
Now, just to check it out across the web browser: http://yourmachine/repos. You’ll get whatever you have imported showing up to peruse. Once you upload your original layout from the local SVN server, you’re now free to use it remotely on another machine. As long as you are connecting to the Subversion server with the user account(s) that you created earlier. Let’s give it a shot.
[me@mylappy ~] mkdir mytestproj
[me@mylappy ~] svn co http://yoursvnserver/repos/mytestproj
Authentication realm: <http://yoursvnserver:80> Subversion repos
Password for ‘youruser’:
A mytestproj/main
A mytestproj/main/mainfile1.cfg
A mytestproj/configurations
A mytestproj/configurations/testconf1.cfg
A mytestproj/options
A mytestproj/options/testopts1.cfg
Checked out revision 1.
d) Edit & Commit
As you can see, you’ve checked out revision 1 from the Subversion server. Now you can edit some things and commit the changes back to the Subversion server.
[me@mylappy ~] cd mytestproj
[me@mylappy ~] vim configurations/testconf1.cfg — Add or delete something and save.
[me@mylappy ~] svn commit -m “Added a line to testconf1.cfg.”
Sending configurations/testconf1.cfg
Transmitting file data .
Committed revision 2.
The nice thing about this then, is that you can delete all of the directories that you just checked out on your machine. The only reason you checked them out, was to edit them, and then send them back up the line. Web browse to your server to check out the different files.
e) Adding/Deleting Items
Now this is all fine and dandy, but how do you add more files to an already existing repo directory? Easy, with the add argument. Go ahead and checkout your latest and greatest, copy a file over to a directory, add, then commit the changes.
[me@mylappy ~] svn co http://yoursvnserver/repos/mytestproj
A mytestproj/main
A mytestproj/main/mainfile1.cfg
A mytestproj/configurations
A mytestproj/configurations/testconf1.cfg
A mytestproj/options
A mytestproj/options/testopts1.cfg
Checked out revision 2.
[me@mylappy ~] cd mytestproj
[me@mylappy ~] cp /etc/yum.repos.d/CentOS-Base.repo configurations/
[me@mylappy ~] svn add configurations/CentOS-Base.repo
A configurations/CentOS-Base.repo
[me@mylappy ~] svn commit -m “Added the CentOS Yum repo file.”
Adding configurations/CentOS-Base.repo
Transmitting file data .
Committed revision 3.
To delete items simply use delete instead of add. Commit your changes back up, and you’re good to go. It’s as simple as that. Go back over to your web browser again and you’ll notice the revision number should say 3. You’ll be able to click through the files to pick our your differences as well.
f) Reverting Back:
Ok, this is all great but how do I revert back to an older revision…isn’t this the point of Subversion? Yep, it’s easy. If you’re not sure as to what revision you’re at…check out the log command. This is why you put a message in every commit. Short and to the point, but enough information to ring a bell that you perhaps forgot about.
[me@mylappy ~] svn log http://yoursvnserver/repos — For the entire repository
[me@mylappy ~] svn log http://yoursvnserver/repos/mytestproj — For the specific project
You’ll get a nice complete list of revision numbers along with the comments, like I mentioned above. This allows you to pick which revision you want to check back out now.
[me@mylappy ~] svn co -r 1 http://yoursvnserver/repos/mytestproj
This command will drag down revision number 1.
4) Access control lists
Usually, you don’t want to give every user access to every repository. You can restrict repository access per user by using ACLs. ACLs can be enabled with the AuthzSVNAccessFile file option, which takes a file name as its parameter. For instance:
AuthzSVNAccessFile /etc/svn-acl-conf
You can add this to the relevant Location section:
<Location /repos>
DAV svn
SVNParentPath /var/www/svn/repos
AuthzSVNAccessFile /etc/svn-acl-conf
AuthType Basic
AuthName “Subversion repos”
AuthUserFile /etc/svn-auth-conf
Require valid-user
</Location>
You can then create /etc/svn-acl-conf. This file consist of sections of the following form:
[reponame:repopath]
user = access
Where access can be r (read), rw (read-write), or empty (no access at all). The default ACL is to give users no access to a repository. Suppose that there is a repository named framework to which you would like to give john read access, and joe read and write access. You could then add the following section:
[framework:/]
john = r
joe = rw
It is also possible to create groups in a section named groups, groups are then prefixed with the ‘at’ sign (@) in the access control lists. For instance:
[groups]
staff = joe, george
[framework:/]
john = r
@staff = rw
If you would like to make all repositories readable to all users, you can add a section for the root directory of every repository:
[/]
* = r