Several developers and one Subversion's working folder

Question

Hi All,

We are work with huge script-language web-site, which difficult to deploy on each developer workstation. Are there any body who run into situation when several developers have to work in the one subversion's working folder at the server?

Answer 1

This just sounds wrong. How are you going to manage separate log ins, concurrent changes? Use multiple WCs for your own sanity!

It seems you are taking 60% of the good stuff out of source control and throwing it away.

Answer 2

"...several developers have to work in the one subversion's working folder..."

No, they don't have to. That's just abusing the VCS.

If you do this, it will hurt. If you don't want it to hurt, just don't do this. It's as simple as that.

(Now, if you tell us why you think they have to, we might be able to point you at a solution.)

Answer 3

Set up an automatic integration tool that will update your test-server with the most recent version on each commit. That way each developer can edit locally and commit. See Cruise Control for an example of such a tool.

Answer 4

The right way to do this is for everyone to have their own working copy. If you want the website to be updated automatically when someone commits a file, then on the Subversion server, set up a post-commit hook script which will ftp or scp (or whatever protocol) the file over to the web server.

I've done this a couple of times, and it works great. Subversion is designed to do things like this.

Answer 5

You could set up a development server identical to your production server, and have each user use the SVN client to check the files out to their own directory on the development server. Edit and test the files remotely, then commit back to the repository, and export (or checkout) to production when you're ready to publish a release.

Answer 6

It sounds like in your organization there are change control fears as well as a lack of continuous integration practices that make scaling up development and disaster recovery more difficult.

You need to convince your stakeholders that your developers should be working from a branch and that your production environment should have a scriptable way to deploy. If you require a proprietary installer (ISS etc) then make the deployment script work with the default install as well as a production tuned system.

Your developers make changes to a branch and they can use continuous integration methodology to deploy that branch to a test / staging server. Then when your stakeholders accept the operation of the staging server you deploy the changes to the production server. If that deployment fails then any disaster recovery would also fail. If your disaster recovery fails then your source control technology has zero value to your organization. Disaster recovery needs to be part of your acceptance tests.

This works even if three developers take turns on one workstation which also serves as the staging server. Each has their own user account and separate working directory, and the staging server would simply be a centralized directory.

Answer 7

You will be in for a world of pain if you do this. You're losing nearly all of the advantages of having a VCS. Essentially, you've relegated SVN to the role of a backup tool. That is not what a VCS is supposed to do. Also, as soon as you've got multiple clients working on the same WC at the same time, you're going to have trouble. At the very least, there will be lock contention that will require you to run "svn cleanup". If you're accessing the WC over a network share, the results can be far, far worse since SVN's locking mechanism doesn't work over network shares. You'll destroy the WC, possibly in a non-obvious way that results in erroneous changes being included in subsequent commits. The SVN documentation warns against using multiple clients over a network share.

Save yourself the version control problems, the developer communication problems, and the integration problems and give each developer their own place to work. Either have separate directories on the main server, or (even better) get them set up to run the site locally. You'll never discover your integration/deployment problems with a shared WC, and you'll still miss some with a shared server.

Answer 8

As everyone noted, you're giving up the benefits of version control with your proposed setup, making life for your developers hard on an ongoing basis (as opposed to the one-time cost of fixing this), and risking serious damage. Don't do this.

If it's hard to deploy on workstations (perhaps because there's a lot of software with sensitive configuration), then I see two good alternatives:

1. Give each developer their own private space on the server, that only the development team can access. This means that server configuration only needs to be done once, but every developer can work privately without breaking things.
2. Take an image of your production server, and modify it enough that it will run in a VM on each developer's workstation. Use that for local deployment, and then deploy to the production server from the repository.

Answer 9

Hi All, Thank you for your answers. Our web-site is using some specific software which we don't have possibility to deploy on the developers workstations. Yes, all developers have own logins to SVN, however at the moment they are have to work on the one working folder on the server. The main question: how to keep SVN and working folder synchronized when several developers implements several different tasks.