Multiple developers and one Subversion working folder
"... multiple developers should be working in the same subversion working folder ..."
No, they don't need it. This is just an abuse of the VCS.
If you do this, it will hurt. If you don't want it to hurt, just don't. It is so simple.
(Now, if you tell us why you think they should do this, we can point you to a solution.)
source to share
The correct way to do this is for everyone to have their own working copy. If you want the website to automatically update when someone commits the file, then on the Subversion server set up a post-commit script hook that will transfer the ftp or scp file (or whatever protocol) to the web server.
I have done this several times and it works great. Subversion is designed to do this.
source to share
As everyone has pointed out, you are giving up the benefits of versioning with your proposed installation, making life for your developers unswervingly ongoing (as opposed to the one-time cost of a fix) and risking serious damage.Don't do it.
If it is difficult to deploy to workstations (perhaps because there is a lot of confidential software out there), then I see two good alternatives:
- Give each developer their own private space on the server, which can only be accessed by the development team. This means that the server configuration is only required once, but each developer can work confidentially without breaking anything.
- Take a picture of your production server and it's enough to run in a virtual machine on every developer workstation. Use this for local deployment and then deploy to production server from repository.
source to share
You can set up a development server to be identical to your production server and each user uses an SVN client to check the files against their own directory on the development server. Edit and test the files remotely, then go back to the repository and export (or extract) to production when you're ready to publish the release.
source to share
It looks like your organization has concerns about change control and a lack of continuous integration methods that make it difficult to expand your development and disaster recovery process.
You need to convince your stakeholders that your developers need to work in the branch and that your production environment needs to be scripted. If you need a proprietary installer (ISS, etc.) then create a deployment script with a default installation as well as a production system configured.
Your developers commit 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 staging server operation, you deploy the changes to the production server. If this deployment fails, any disaster recovery will fail as well. If your disaster recovery fails, your source code control technology is of zero value to your organization. Disaster recovery should be part of your acceptance test.
This works even if three developers take turns working on the same workstation, which also serves as a staging server. They each have their own user account and separate working directory, and the staging server will just be a centralized directory.
source to share
You will be in a world of pain if you do this. You lose almost all the benefits of having a VCS. Basically, you've put SVN aside as a backup tool. This is not what VCS is supposed to do. Also, once you have multiple clients working in the same toilet at the same time, you will be in trouble. At least there will be a lock conflict that will require you to run "svn cleanup". If you access the WC over a network share, the results can be much worse because the SVN blocking mechanism does not work over a network share. You will destroy the WC in a possibly non-obvious way that will result in erroneous changes included in subsequent commits. The SVN documentation warns about using multiple clients over a network share.
Save version control issues, developer communication issues, and integration issues, and give each developer their own place to work. Either have separate directories on the main server, or (even better) configure them to run the site locally. You will never find integration / deployment issues with shared WC and you will still be missing some with shared server.
source to share
Thank you for your responses. Our website uses some specific software that we do not have the ability to deploy to developer workstations. Yes, all developers have their own SVN logins, but at the moment they have to work with one working folder on the server. The main question is how to keep SVN and working folder in sync when multiple developers are doing several different tasks.
source to share