How to properly create an SVN repository that is accessible via http? (inside public_html)?

Question

Here's the situation:

subversion is already installed in the server and I have access to one of the shared accounts in the server (not the root), and this shared hosting account has SSH access.

I want to create a repository where I can commit the PHP files i'm working on, and when I commit it should be viewable in a browser that is why I was thinking of creating the repository folders inside public_html is this a correct way to do this? How about the security of the server? If not what is the correct and proper way to do this?

I would also need help in creating the repository via SSH with Putty. Is there a step-by-step guide online for this?

Server information is as follows:

cat /proc/version - output this:

Linux version 2.6.9-89.0.3.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-11))

svn --version - output this:

svn, version 1.1.4 (r13838) compiled Aug 10 2009, 23:17:10

• ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  • handles 'http' schema
  • handles 'https' schema
• ra_local : Module for accessing a repository on local disk.
  • handles 'file' schema
• ra_svn : Module for accessing a repository using the svn network protocol.
  • handles 'svn' schema

Answer 1

The correct way to do this is to use a web bridge to SVN, such as websvn or viewsvn (there are several). You can set these up to expose any repository as a website.

As to creating a new repository, see the SVN "Red-Bean" reference at http://svnbook.red-bean.com/

Answer 2

I want to create a repository where I can commit the PHP files i'm working on, and when I commit it should be viewable in a browser.

I'm not sure I understand your question. Do you mean that the repository should execute your PHP, i.e. that your Subversion repository should also be your PHP server? I strongly recommend against it.

A source control repository and an application server are completely different things. They serve different roles; should be accessed by different people (developers vs. end-users); should have different monitoring and SLA policies; different hardware, and whatnot. You also probably don't want every committed change to be automatically deployed to your production environment.

Answer 3

The Red Bean book also has a number of sections on integrating SVN with apache, etc. But before you start working on a solution, you need to define what you're trying to do more thoroughly. What is your usage model?

For example, will you commit to SVN repository via svn+ssh, or via svnserve, etc?

Do you want to see full revisions, history, changesets from the web interface? Or just the head?