views:

298

answers:

1

I've just started working for a new firm as an in-house web developer. Up until now they have been outsourcing development work of their websites and decided to bring them in-house, hence my employment.

I've only every worked on projects on my own and have never used version control.

We've just hired another web developer to work alongside me and I've been asked to look into version control as there will be up to 4 people who need access to the website files.

I'm completely out of my depth in relation to getting a good setup of Apache sites when running under version control.

We currently have a local development web server running Ubuntu and Apache2 and a live web server at a datacenter. The local server hosts multiple websites each having a sub folder in the web root i.e. /home/htdocs/sitename_com and /home/htdocs/sitename2_com. We currently edit a websites files on PC's using samba shares or FTP. What I want to do is install SVN so that users can checkout a working copy of the code of a single site, make any changes and then commit the changes back to the repository. We would then need to be able to test the sites and then when happy would FTP the files to our live server.

Now I realised early on when thinking about setting up SVN that when a user checks-out a working copy on their machine they can't actually test the changes until they commit them back into the repository. This is because the files are PHP and need to be executed via a web server. Now I could just put XAMP on each machine but then this would have a different configuration to the Apache2 install on the development server. This for me is not an option.

I guess the working copies would have to be created not on the users machine but inside the web root of the development server, that's the same server as the repository itself. I could create a samba share to the users working copy folder so that they can make changes from their windows machine.

I've got a few questions:

  1. Can you view a website stored in a repository in the browser without having to check it out first?
  2. If no then the site would have to be checked out to a location within the web root of the same server?
  3. Should I use a repository for each site or one repository with sub folders for each site?
  4. When a user commits the changes they have made to a working copy back to the repository we need to test those changes and everyone else's changes that may have been committed. Is it possible to get SVN to copy the committed changes to a staging area within the web root for testing?

Or is there a better way of doing this?

I can't seem to find any clear information on the Internet regarding best practises when setting up SVN for websites. It's clear how SVN relates to source code of a C++ app where you would just compile your working copy on your machine for testing but websites have to run on a web sever and each working copy would need to be tested on the web server before checking back into the repository.

The are multiple sites on the server with multiple users working on each site. We need to be able to work on the sites at the same time, test all the changes in a staging area and would also like a live area where we will have an exact mirror of the live site where we can merge any changes and test before uploading to the live server.

All the examples I have found on the Internet use examples of a single server hosting a single site. In my case our live server hosts about 10 sites.

If anyone could give me advice on how to set this up, Apache directory structure, repository structure etc. I would really appreciate it.

Thanks in advance!

+1  A: 

We had some similar needs and did the following:

  • Set up an SVN server (Git was an option, but too complex in this case as there were no very good GUIs available back then) - we are using the svn-daemon that comes with SVN.
  • Set up testing web server, running the software you need (Apache, etc.).
  • Have users update and commit their changes to and from the SVN repository.
  • Set up a simple script that does something like the following script. Basically pulling all changes from the SVN server every hour (or whenever needed).

    cd /var/www/testdata/

    svn update -f

Previously you have to checkout the repository, of course.

You don't have to worry about users overwriting each other's changes. SVN detects that and forces the user who commits colliding changes to merge them).

This would allow for quick testing of changes made. Optionally you can also install Redmine, which integrates tightly with SVN, allowing you to tightly integrate the SVN repository with tickets and bug reports.


It almost sounds like what you need is Git though. Git allows for separate branches (for instance, for each user, or feature that is implemented) that are merged when they are ready.

If you want to review every single commit made, you could alternatively check out each commit/revision into its own web sub-directly, which would allow you to access the source code state of each commit using your web browser.

But a script on the server-side is needed in any case.

BastiBense