Using Subversion With Multiple Developers

Hi guys. I’m a PHP Developer for an in-house IT Team at an Insurance Brokers. I setup an Ubuntu development (internal) server a few months ago and would like to implement sub-version so we can all develop the same website but with the added functionality sub-version provides.    At present we all use Dreamweaver (please don’t shout). Dreamweaver has a simple ‘Check In / Check Out’ function, so it remembers who opened a file last. The site is stored on the local development server and we all map a drive to the site root. So to change a file, we open Dreamweaver, try and open the file – and if someone has opened it since I have, Dreamweaver tells me it’s checked out by Mr X – I ask him if I can take the file, he says yes, and I open it. A rather crude control measure I’m sure you’ll agree – hence why we’d like to use subversion.    The thing is, neither I or any of my colleagues have used sub-version in a commercial environment. While I’ve done my best to read up on Sub-version, I wonder if someone could explain how it works in the ‘real world’.    For example, if I have a repository with a project in it, do all 3 developers have their own local working copy (I mean actually on their workstation, with a web server installed too)? At present we have a single drive we all work from with a single (internal) url we all use to view our changes…    Any help or overview/explaination anyone can provide would be greatly appreciated.

Last updated 12 years ago

It's a big question to answer in a small post. In your example, you'd run a Subversion server on the central server with a repository that each user would then 'Checkout' a copy of to work on on their own machine. This is stored on the local filesystem and the user themselves doesn't need to run a webserver. Once they have changed something the user then commits that change back to the central server via Dreamweaver. Subversion will warn if anyone else changed the same file and provides a mechanism to handle the conflict. It is possible to 'lock' files, but in a small scale environment that is normally an unnecessary overhead.   I find this guide most useful as an introduction to Subversion and Version control concepts: http://betterexplained.com/articles/a-visual-guide-to-version-control/  Let us know if you have any specific questions we can help with.   Best Wishes,   Ian

Thanks for your reply Ian.  I setup Subversion on our Linux development server. I added a couple of rules to the commit hook so a) It prompted the user to include a note when they committed and b) It updated (If i recall correctly) a 'checked out' version of the site so we could visit it via 'http://devsite.local'.  How does this all work though? Would each developer have to 'Update' their checked out version of the site every morning?  Does this mean every developer has a copy of the site on their local machine?

sjwdavies;111641Would each developer have to 'Update' their checked out version of the site every morning?    Does this mean every developer has a copy of the site on their local machine?

 Yes, and yes. I suggest you read the fine manual, as it explains this very basic & core principle of how Subversion works. Start with http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html

Thanks Andy. I've had a look at the manual in depth and was hoping for a real person with experience of usin subversion to have a two way informative chat with me.  I setup a simple site today and was able to check it out and commit chains from two different applications - Dreamweaver and Netbeans.  I've set it up so that after every commit it updates a working copy (defined as an apache virtual host) so we can see changes immediately.  How would this work in a branch environment? I mean in the real world how do developers test their branch as they're developing it?

Most developers test their changes on their own workstation, or in a "sandbox" environment, before committing to the repository.    If you're using branches, and want to have a site updated with the branch activity upon commit, you'd have to do the same thing you're doing today, but updating a different location. This will become unwieldy if you do a lot of branching, which is why it's preferred that developers test locally, then commit to the repository when appropriate.

Thanks Andy!  Just the sort of real life advice I was after.  I did think of, 'would setting up a http://brancha.site.local' for each branch be of benefit? And thought that might confide itself to only the larger projects.  As for branches, if I'm changing the site say to add a new section, am I correct in assuming I should update my branch FROM the trunk on a regular basis so that the branch doesn't become too out of date?

sjwdavies;111660I did think of, 'would setting up a http://brancha.site.local' for each branch be of benefit? And thought that might confide itself to only the larger projects.[/quote]If they're long-running branches and multiple people need to review things, it may. It may also end up being more overhead than it's worth.    [QUOTE=sjwdavies;111660]As for branches, if I'm changing the site say to add a new section, am I correct in assuming I should update my branch FROM the trunk on a regular basis so that the branch doesn't become too out of date?

You would merge from trunk regularly.