Converting a development team from FTP to a Versioning System

Question

I work at a small LAMP Development Studio where the idea has been to just get the code done and go on to the next item on the list.

The team works in Zend Studio 5.5 connected to the Live server via FTP or SFTP. What they love about this is the speed of their deployment of code (since its just modifying live code).

But of course this is not good due to many obvious reasons.

I would like to move them to a Versioning System (CVS, SVN or any other tool) but the catch is, I am not their senior so I need a carrot for them to start using this.

What kind of setup would I need to build on their machine so they can code along as usual?

What I would do is create this setup on my machine and then show them.

I know this is kinda unusual but it's turned into a passion of mine to change their way of thinking from the usual hacking of code to structure and elegance. Thanks.

UPDATE (for Jonathan Leffler's answer):

1. Yes
2. No
3. Yes, they really do

Question also, the studio makes a centralized CMS system that is hosted on hundreds of sites, they need to modify individual sites, should the sites be in the main compository or within their own one?

Answer 1

Questions:

1. Have you (they) never had a disaster where you (they) needed to revert to a previous version of the web site but couldn't because they'd broken it?

2. Do they use a staging web server to test changes?

3. Surely they don't modify the code in the production server without some testing somewhere?

I suspect the answer to the first is "yes (they have had disasters)" and the second "no", and I hesitate to guess the answer for the third (but. from the sounds of it, the answer might be "yes, they really do"). If that's correct, I admire their bravado and am amazed that they never make a mistake. I'd never risk making changes direct on a live web site.

I would recommend using a version control system or VCS (any VCS) yourself. Work out the wrinkles for the code you look after, and develop the slick distribution that makes it easy (probably still using SFTP) to distribute the VCS code to the web site. But also show that preserving the previous versions has its merits - because you can recover who did what when. To start with, you might find that you need to download the current version of whatever page (file) you need to work on and put that latest version into the VCS before you start modifying the page, because someone else may have modified it since it was last updated in your master repository. You might also want to do a daily 'scrape' of the files to get the current versions - and track changes. You wouldn't have the 'who', nor exactly 'when' (better than to the nearest day), nor the 'why', but you would have the (cumulative) 'what' of the changes.

---

In answer to comments in the question, Ólafur Waage clarified that they've had disasters because of the lack of a VCS.

That usually makes life much easier. They goofed; they couldn't undo the goof - they probably had annoyed customers, and they should have been incredibly annoyed with themselves. A VCS makes it much easier to recover from such mistakes. Obviously, for any given customized site, you need the (central) backup of the 'correct' or 'official' version of that site available in the VCS. I'd probably go for a single repository for all customers, using a VCS that has good support for branching and merging. That may be harder to deal with at first (while people are getting used to using a VCS), but probably leads to better results in the long term. I'd seriously consider using on of the modern distributed VCS (for example, git), though lots of people use SVN too (even though it is not a distributed VCS).

Answer 2

you can use tortoise svn client to create and work with a repository on your local machine on some other file path then your working path is....

maybe try to setup and use that for yourself and show them after a while what it can do for you. another cool thing might be installing trac (http://trac.edgewall.org/) on your server if you have access and privileges to do so, or maybe in some virtual machine on your own development machine. you can map trac to your svn and get svn changes in web interface which you can show to the project manager. maybe he will fall for that he'll be able to see code changes easily through the web interface. of course, you can do that with only apache + svn module, but this is nicer as it offers a path to ticketing and roadmapping (milestones and stuff which managers might dig :o) )..

good luck anyhow :) . at least, use it for your work on your local machine as there's only a gain for you doing that.

Answer 3

You can install SVN on your local system for the demo. There are some tools to integrate Zend and Eclipse to SVN. I think in addition to doing a demo of SVN, you should probably give them a presentation of some of the benefits it will bring (probably during the demo).

Go to this link for some ideas: Do I Really Need Version Control?

Answer 4

Here's one trick that everyone will love:

I include this 'plugin' in most of my production sites: Ofcourse, you need to create a limited-rights robot svn account for this first and svn must be installed on the server.

    echo(' updating from svn<br>' );
    $username = Settings::Load()->Get('svn','username');
    $password = Settings::Load()->Get('svn','password');
    echo(" <pre>" );
    $repos = Settings::Load()->Get('svn' , 'repository');
    echo system ("svn export --username={$username} --password {$password} {$repos}includes/ ".dirname(__FILE__)."/../includes --force");
    echo system("svn export --username={$username} --password {$password} {$repos}plugins/ ".dirname(__FILE__)."/../plugins --force");

    die();

Make sure you put this behind a .htpasswded site ofcourse, and make sure you do not update the 'production settings' from SVN. Et voila, You update your complete code base with one HTTP query to your site :) SVN overwrites the files automatically, there's no hidden files or folders left behind and its easily adapted to update or revert to a specific version. Now all your team needs to do is commit to their SVN repository, run this piece of code on the testing environment, make sure everything works and then run it on production :)