Setting up subversion for Production and Beta/test site

[EvanAgee]

Greetings All,

 

I'm new to subversion, but I have it setup on my web server (MediaTemple.net) and I've been able to successfully create a repository, etc. My question is more about workflow.

 

So the situation is quite common, I have www.mywebsite.com that's the live/production version of my project and I have beta.mywebsite.com which is a test/development version of the same site. About 99% of the code base is the same for both sites but they're are some configuration variables that are different to keep them from interfering with each other.

 

My goal workflow is this:

1. Make an update on my local machine, commit those changes to beta...

2. Preview those changes on beta to make sure all is well

3. Pull (or update) those changes into www once I've verified that everything is good to go.

 

Could anyone give me a little help with how I would set this up? I'm not sure why it has been so confusing to this point.

[gizmola]

It's confusing because there is no established standard way of handling this.  Different people have different ways of doing it.  One way is to have your beta and production be svn sandboxes.  Thus whenever you want to bring your latest changes in, you simply do an svn up.    The only downside to this is that you also have the svn cruft. 

 

I've seen elaborate systems using a combination of svnlook used in scripting up systems that find changes, and dump them into a staging directory, then use rsync to update the remote server.

 

One thing to defnately look at is precommit and postcommit hooks.  They can be used to do all sorts of things, like for example, in precommit, you could run php -l and disallow the commit if a php file has a syntax error.

 

[EvanAgee]

Thanks Gizmola!

 

I'm curious, since there isn't a well-known (or suggested) method for dealing with this case, is there a better workflow that I haven't yet considered? I know it's possible to have 2 different projects, but I figured there had to be some way to connect the projects together and share updates between them.

 

I'll have to research the svn sandboxes idea.

 

Thanks much!

[gizmola]

Thanks Gizmola!

 

I'm curious, since there isn't a well-known (or suggested) method for dealing with this case, is there a better workflow that I haven't yet considered? I know it's possible to have 2 different projects, but I figured there had to be some way to connect the projects together and share updates between them.

I'll have to research the svn sandboxes idea.

 

Thanks much!

 

A sandbox is the same as a working copy.  So basically you do the same thing on your beta and production server as you do for development -- you do an svn co of the project into the appropriate location on each server.  For configuration files that need to be modified, the best thing to do is to check a version of these into svn that has a template of what you need, but isn't the actual filename itself.  For example, if it was the httpd.conf file, you might name that file httpd.conf.dist.  You then copy the file and edit it as needed, but don't ever check it into the repository.  Typically you set these files up once, so there's no need to mess with them once you have them configured.

 

As far as seperate projects, I'm not sure what you mean by that.  You can setup as many svn repositories as you want, but this is often not very convenient.  An alternative is to to have the projects in the same repository, only the top level subdirectory is the project.  When you checkout files you simply specify the location of the project you want rather than pulling out the entire repo.

 

What I typically do is this:

 

/tags

/branches

/trunk/

And in trunk I'll have:

 

/trunk/project1

        /project2

        etc.

 

 

[roopurt18]

Configure your repo so you can access it from home.

 

I would set up the repo directory as:

$REPOPATH
    /project1
        /tags
        /branches
        /trunk
    /project2
        /tags
        /branches
        /trunk
    /project3
        /locationA
            /tags
            /branches
            /trunk
        /locationB
            /tags
            /branches
            /trunk

 

Let's say you're developing project1.

 

At home you checkout project1 for local development.  When you're done, commit your changes to /project1/trunk

 

Then go to beta.domain.com and svn update the beta document_root with trunk.  This will move the trunk you committed from local to the beta area.  Test the beta site.

 

Make any necessary changes and commit back to trunk.  SVN update your local copy and make sure it still works in local.  It should work in local and beta.

 

When you're finally satisfied, create a tag of your project to the next version:

$REPOPATH
    /project1
        /tags
            /v0.0.0
            /v0.0.1
            /v0.0.2
        /branches
        /trunk

 

Now go over to the production and export (not checkout) the latest version into the production doc_root.

[gizmola]

The problem with svn export is that it pulls out the entire tree.  It does however, solve the issue with having a bunch of .svn folders filled with svn files.

 

Roopurts method is a variation on mine, but truthfully i don't see the benefit of having seperate tags,trunk and branches directories in the same repo.  About the only thing it does is allow you to name tags as he did in his example.  You can accomplish the same goal in my example, by naming a tag project.0.0.1.

 

Making a version tag for a release is however, a great practice to get into.

[roopurt18]

but truthfully i don't see the benefit of having seperate tags,trunk and branches directories in the same repo.

 

It's a personal preference thing.  I much prefer to filter the repo based on project and then releases and branches for the project.

 

Part of this is because I manage a dozen or so projects, some with 20 or 30 versions.  When I go to export the latest and greatest version of ProjectA, I only want to see the versions for that project and not the other 120 versions from all my other projects.

 

The problem with svn export is that it pulls out the entire tree.

I'm not quite sure what you mean by this.  When I export:

/repos/ProjectA/tags/v0.0.10

to

/var/www/ProjectA

 

it only exports the folders and files under "/repos/ProjectA/tags/v0.0.10"

[gizmola]

What I mean is that svn export pulls out every file.  When you have a working website with hundreds of files and images, it's not really that great to have to replace every existing file in the webroot just because you updated 2 scripts.  It would be great if svn export let you specify just the files changed in a revision, but unfortunately it doesn't seem to allow for that.  When you specify a revision you get everything that's been commited up to that revision, and you're not even allowed to specify a revision range.  For that reason, it's not the ultimate solution it might be for this.  If it was, I'd 100% agree with you.

[roopurt18]

Ah.  But if the SVN is on the same machine then the export should run fairly quickly.  Even if it's not, as in my case at work, I export on MachineA, zip the file, SSH it to production, and then unzip it.

 

Regardless of how many files the project contains and how many are updated, I recommend exporting the entire version.  The reason is that when you created that version you tested it with all of the files.  If you decide to do only update those two files on the server, but accidentally miss one, then you run the risk of introducing bugs.

 

Surely exporting the entire project, even with hundreds of files, can't take more than a few minutes?