views:

2310

answers:

8

We have a php project that we would like to version control. Right now there are three of us working on a "Dev" version of the project that all have our Eclipse linked to it with just an external folder, and thus no version control.

What is the right way, and what is the best way, to version control this (not necessarily the same I dont think)

We have a SVN set up but just need to find a good way to check in and check out that lets us test on the dev server. Any ideas?

A: 

Each of you could run it locally, or on your own dev server (or even the same one with a different port...).

Shawn Simon
+12  A: 

We were in a similar situation, and here's what we ended up doing:

  • Set up two branches -- the release and development branch.
  • For the development branch, include a post-commit hook that deploys the repository to the dev server, so you can test.
  • Once you're ready, you merge your changes into the release branch. I'd also suggest putting in a post-commit hook for deployment there.

You can also set up individual development servers for each of the team members, on their workstations. I find that it speeds things up a bit, although you do have some more setup time.

We had to use a single development server, because we were using a proprietary CMS and ran into licensing issues. So our post-commit hook was a simple FTP bot.

Marcel Levy
A: 

One possible way (there are probably better ways):

Each of you should have your own checked out version of the project.

Have a local copy of the server on your computer and test it there throughout the day. Then at the end of each day (or whenever), you merge together whatever you are ready to test, and you check it out onto the dev server and test it.

cmcculloh
+1  A: 

One way to use subversion for PHP development is too setup a repository for one or all three developers, and use this repository, more as a syncing tool, than true version control.

You could,

  • Make a repo

  • Add your entire PHP document structure of your project

  • Checkout a copy of this repo into the correct spot on your dev server

  • Use an svn hook, that activates on commit

This hook, will automatically update the contents of the dev sever, whenever anybody on the team checks in any code.

Hook resides in:

svn_dir/repo_name/hooks/post-commit

And could look like:

/usr/bin/svn up /path_to/webroot --username svn_user --password svn_pass

That will update your working copy on the dev server to the latest check in.

Justin Tanner
+2  A: 

Here is what we do:

  • Each dev has a VM that is configured like our integration server
  • The integration server has space for Trunk, each user, and a few slots for branches
  • The production server
  • Hooks are in Subversion to e-mail when commits are made

At the beginning of a project, the user makes a branch and checks it out on their personal VM as well as grabs a clean copy of the database. They do their work, committing as they go.

Once they have finished everything in their own personal space they log into the integration server and check out their branch, run their tests, etc. When all that passes their branch is merged into Trunk.

Trunk is rebuilt, the full suite of tests are run, and if all is good it gets the big ol' stamp of approval, tagged in SVN, and promoted to Production at the end of the night.

If at any point a commit by someone else is made, we get an e-mail and can merge those changes into our individual branches.

dragonmantank
A: 

Beanstalk has built-in post-commit hooks for deploying to development, staging, and production servers.

Jarin Udom
A: 

Another tool you can use for the builds is TeamCity which is free for 20 build configurations (enough for most small companies/projects.) This way you can run your tests as well as schedule builds.

Mladen Mihajlovic
A: 

What about something distributed? You can start for example with Mercurial, try different workflows, and see which one fits you the best.

mercu43