CODEWITHSUNDEEP
svnversion-control
Mala
Mala

Reputation: 14803

implementing version control for webdevelopment

I'm trying to make the move into version control, as my projects are getting larger. Currently my development goes something like this:

My local platform is Gentoo, Linux. I've looked a little into SVN, but I think it might not suit my needs, in that my local webserver (and Unison) would only be able to access currently checked-out code, and so on. I might be wrong, but I don't know very much about this.

Could someone please walk me through setting up some kind of version control on existing code, which would result in the latest version being accessible to a local webserver and which doesn't clobber access times for unedited files? (I don't want Unison uploading every single file every time I make a change)

Upvotes: 6

Views: 420

Answers (4)

timdev
timdev

Reputation: 62864

I use subversion for this, and it works well.

Typically I develop away, until I have something cleaned up for a release.

At that point, I'll create a branch named something like release-. I'll hop on the production system and check out my newly created branch. For several projects, I'll have a staging area that runs on the production system.

For instance, I might have a directory tree that looks like this:

/web/sites/release-1
/web/sites/release-2
/web/sites/release-3
/web/sites/release-4
/web/sites/stage ==> release-4
/web/sites/live ==> release-3

"stage" and "live" are symbolic links, and are what Apache has for DocumentRoot for virtualhosts www.example.com and stage.example.com)

This setup allows me to test things pretty carefully in the actual production environment, and then cut over by swapping symlinks.

By branching before deployment, I can make emergency fixes on production in the rare case I need to do so. I can then merge those changes back to the trunk whenever it's convenient and appropriate.

One last tip: If you use working copies of subversion projects in a production environment, you need to keep apache from allowing people to browse the .svn directories in your project:

in httpd.conf:

<Directory ~ "\.svn">
    Order allow,deny
    Deny from all
</Directory>

Upvotes: 2

Tom Anderson
Tom Anderson

Reputation: 47163

To expand on @Nathon's answer. You want to do:

cd ~/code # this is where your code lives now
# set your local webserver to run from *this* directory
hg init
hg add *
hg commit -m "Initial checkin"
hg clone ~/code ~/staging
cd ~/staging
# set Unison to run from *this* directory

Do your development in ~/code, checking it with your local server. Commit whenever you like. When you get something that works, tag it. Then do:

cd ~/staging
hg pull
hg update your-tag-name
# run unison.

I get the impression that you also want your local server to run from the staging area, but this seems like a bad idea, since you want to use it to check your work as you go along. If you want a sort of QA environment, you could run a second webserver from staging, but i would only do that in addition to, not in preference to, dev.

Upvotes: 0

nmichaels
nmichaels

Reputation: 50943

Mercurial style:

> cd ~/code
> hg init
> hg add *
> hg commit -m "Initial checkin"

That will get you a working mercurial repository. Read the link for more info on how to use it.

You can clone from your local web server and your live web server to keep things up to date.

Upvotes: 0

GSto
GSto

Reputation: 42350

Here's my current setup, i'm sure you could do something similar:

I use SVN, which is hosted on the main server. There are two servers, development and production. I do all of my work editing on a checkout on the development server, then when changes are ready to go live, I commit them up, and then update the checkout on the production server, which is the live site.

Upvotes: 0

Related Questions