Subversion on a shared development server

Question

I'm thinking about implementing source control at my work. Ideally, I wanted to use Subversion since it seems to be the tool of choice at the moment. However, I seem to have hit a brick wall since it just isn't practical for all our developers to work in local environments. We do web development with Coldfusion and use a shared development server. Changes made to files can quickly be refreshed in the browser.

Our company maintains over 100 sites, and our development server mirrors all these sites on production. We often have to make quick tweaks to 1 of these 100, test it and quickly upload it to production. If we had to download a given site locally, set it up in our local webserver, these small changes would become more time consuming tasks. Also, often are copywriters and less technical folk will want to go into an html page and change copy. This is straightforward in our current shared server setup.

A long time ago we used a source control called NGSource, when you checked a project into the repository, it changed the file permissions to read only. We'd check the file out to the shared dev server, and it would change the permission to read and write. We'd all check the repository to make sure someone wasn't working on a file we thought to work on. This worked well and was explainable to copywriters. The problem was that NGsource client was slow and they might be out of business as far as I know.

So is there a way to implement this changing of file permissions on check in and check out with Subversion? If not, is there a better open source solution? Is it so bad to develop in a shared environment and skip developing locally?

Answer 1

You can use ‘svn lock‘[1] to ensure that no-one else is able to edit the file you're currently working on.

[1] http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.lock.html

Answer 2

Can you explain why do you need "read only" mode for the files? as you describe it, you can maintain a working copy on the production site. So developers or copywriters, just connect to the site, edit it and commit their changes directly from production site.

Answer 3

Hi Danny,

I am version control manager for a development company that makes and maintains web applications and web sites, though not nearly as many as yours. I understand the complexity in getting 100+ sites to work correctly (if at all) on n developer's/copyrighter's local boxes and believe it is a legitimate reason to not check out locally to each.

About Our Process

In our process, any change that is made locally first goes to a staging environment where it is vetted against a reasonable representation of the customer's data, then when it is deemed good it finally is transfered to a production environment. We do not install a versioned codebase in Production, because:

1. File system overhead: SVN keeps something equivalent to twice the information in a checked out directory. This is why you can diff and revert without being connected to the server.
2. Security: Having the extra .svn directories is just one more vector of attack. This can be compensated for, but does the benefit outweigh the cost? For us, no.

Instead we use a tool like RepliWEb to copy the codebase from Staging to Production.

About Your Possible Process

Would it work if you had one staging environment with all 100+ sites configured, running, and under source control? This is the environment all developers and copyrighters would use to make modifications, and then they would commit. When the modifications were deemed good, a tool like RepliWeb could transfer the version in Staging (sans the .svn directories) to Production. If the file system overhead and security risks are negligible for your company, than RepliWeb would be replaced by simply doing a clean checkout of the site in Production (making sure to remove any previous artifacts).

I hope this helps.

Thank you,
Zachary

Answer 4

I can imagine your pain but you did not tell us what's wrong with your current procedure ;). It is "dont fix if it aint broken" after all. And only because everyone uses SVN/GIT etc. there is no garuantee that its for you.

We have similar requirements here but luckily still manage to have local checkouts and local webservers that some people use before committing. It is the recommended way. There is a shared development environment for others that who mount via samba or nfs. But still everyone has their OWN workspace parked on it. People that work on the frontend alot and check in uncritical changes use a webinterface to invoke svn updates on the main staging system in the datacentre or on the target (clients) system. Its their discretion and their fault when things break. The steps could be completely automated using svn hooks too of course.

Our results are acceptable so far.

If you think the overhead for personal workspaces is too high for your business case then no source-control that I know can help you. You can still lock files in svn so people can not check in changes until it is unlocked but this is so very 1990 ...

After all what are the goals of source control? Some I can think of:

• Paralell development with many people
• Isolation of stable and unstable code
• Transparency and rollback-ability

When you have no concept of a personal workspace and a "user" checking in instead of the anonymous "team" mangling the files, most Source Control features will not work for you, naturally.

Maybe you can have subfolders on your coldfusion server? Decrease personal workspace management overhead by updating all of them automaticly from the Source Control server (usualy not something I would recommend)?

If possible you need to get out of the "we edit on the server" habit first and then think about source controll. The other way round will be complicated ;)

C