Managing Team Development on Shared Website

I need to know the best way to manage team web-development on a shared server (hostgator).

I have done some individual web development on a shared server in the past, and I have always setup SVN through SSH to have a pretty-nice development workflow (version control, quick-commits, work though eclipse/subclipse, etc). However, I also know that with that setup, I had to make some pretty-sophisticated post-commit hooks to export the repository to /public_html; and, therefore, making the repository code testable.

This seems like a tedious and error-prone setup for an entire team. I would like to be able to:

1. Easily test the latest code in the repository.
2. Somewhat easily move the code in the repository to production.
3. Use an IDE like eclipse/subclipse to easily work with the repository.

With this in mind, does anyone know of a good version-control/repository setup for developing a website with a team of about 4-5 people?

Thanks a lot.

EDIT: I am pretty confident that I am stuck with SVN. Not a personal preference, but a limit of my web host. But, it's not as much of a repository problem (can manage with SVN), as much as a problem of deployment. What and How's the best way to deploy repository code to testing and production. I don't have the luxury of a build-server such as Hudson on my shared hosting server. Yes, I can write post-commit hooks, but it seems a little too error-prone and they are already very fancy. If this is the best I can get, then I will have to manage. Just curious if someone has run into another option.

lets get this straight

the best way to work on project with any number of coleagues is throught some svn client. i have a best experiences with tortoisesvn

first thing you should do after you start a new project is to set up project repository like this

your_project
  trunk
  branches
  tags

where trunk represend your newest stable production code. dir branches is for developers who work on project. every developer should have his own branche and of course there should be also a dir for release like

branches
  r01
  developer1
  developer2
  developer3

so course of action should be like this:

• on the begining of every month (depend on activity on project) is established new release (created as branche from trunk)
• new tasks are deal out and every developer create its own new branch
• when developer finalize his branche he merge it back to new release
• after every developer close out his branche and new release is successfully done, admin create a tag called for example 'tags/test-r01.01'

and here comes tools like hudson whitch after he detect new test tag he automatically deploy new test. how, when and where depends of course on configuration

and finally when time is right (every tester do his/her job) admin merge latest release to trunk (our stable code), afterwhitch create new a tag eg tags/r01 from trunk and hudson do the rest of the work (auto deploy new version of our web)

i have however only scratche the surface here, there is a lot of brainstorming around this particular problem on both tortoise svn and hudson manuals. hope this helps

I know you mention subversion specifically, but are you stuck on subversion? I have found that in a multi-person dev environment using git is MUCH better. The merge tracking abilities alone are a lifesaver. And the fact that each person have a full history locally allows for faster history viewing and offline development. You lose a few abilities you have in subversion. The biggest loss is sub-tree checkouts and the ability to do ACLs on subtrees. IMHO, those are worth giving up. A few small scripts and you can have semi-automated deployments using git as well.

I am exploring possiblities of https://bespin.mozillalabs.com/ for my web development. Looks quite promising. an editor and a version control system. fully online. try it for once and see if you like it.

You could use something like:

http://www.assembla.com?affiliate=joedeveloper

(pardon the affiliate whoring)

Which lets you 1-click deploy from a repo and gives you things like Scrum tools and tickets etc.

Other low tech solutions would be to simply make the staging server public_html/ a git repository.

With shell access on the production server you could pull in stable branches when you want.

You example with SVN seems pretty straightforward. I guess what you are getting at with your post-hook commit comment is something like continuous integration or a nightly build process. There are a number of tools that can do that for you.

A good discussion is here: Setting up Continuous Integration with SVN

As for the best source control system for your team in general, it seems like most people who are coming into the game fresh are preferring either git or Mercurial (both are considered distributed version control systems). The biggest criticism of SVN is the difficulty of the branching/merging feature. Most people promote git/mercurial because of the ability to easily branch and merge which allows each developer to have his/her own repository on their local machine and merge their repository with the central repository when they get to specific milestones. This means they don't have to break the build with half working code, but also don't have to go weeks without the benefit of source control while they make really complicated changes to a branch on their local machine..