So we just continued working with our files stored on the shared project server with all problems that come with it: working on the same file (and saving going wrong), accidently deleting a file (and no way to recover it except for the overnight copy that was made), overwriting the server copy with a local copy (and no way to go back), nobody claiming that they broke a file (and no way to find out who did it), etc.

I’m glad that – at my current job – we use SVN, it not only lets us collaborate on projects more easily; It also lets us dig up old versions of code (no need to manually zipping up a project) and see who did what (even on line level). Really, push your tech director to set up some kind of versioning, the juice is worth the squeeze (viz. the effort in setting it up is worth it)!

We’re not using it as it should be though as all the sites produced by us are built on our CMS which is constantly being updated (viz. the trunk). We do indeed create new branches (1.1, 1.2) from time to time, yet our tags are no real svn tags: instead of sub versioning a branch to – for example – v 1.2.1 each project/site we create is a tag (in a normal scenario one would set up a new project from a certain tag).

By this we can use the same repository for all our projects, as they all rely on the same codebase. Only difference between them is the layout, and some projects require some extra modules. Above that all our tags are accessible over HTTP via a subdomain of our svn root url, making all changes directly visible on the temporary url before the site goes live

About GIT: Haven’t worked with it yet. Heard some great things about it though: It’s supposed to be “SVN on steroids” or something like that

It normally doesn’t cause too many problems as on most projects the vast majority of the time there will be only 1 developer working on it and never work on the production environment always in staging – but still it’s not a great system.

Thinking of trying to get him interested in Git, what source control would you recommend?

@balder: a dev machine would a good idea indeed, yet we would still need the steps laid out above as all of our custom files would need to make it onto that dev machine and be callable over HTTP

Now, we could take our SVN server for this at work, since our hoster provides us HTTP access to the SVN tags. And this is actually something we do: develop locally, and then finally upload the files via FTP onto the SVN server. By this our clients – if we give them access to the development version of the site – can see all our commits + our test data (and test files) online

I know, it might sound weird but I have found this a really really good way of working. Just think of the SVN server as an internal machine … maybe that will make it easier to get a hold of the bigger picture after our way of working

And what if a third developer comes in to place, and a fourth and…, will they all get the man’s password in case he gets ill?

Secondly, differences in infrastructure tend to generate unexpected results. It is impossible to duplicate a deployment setup in a development environment, but one should try.

The idea of switching behaviour is understandable, but dangerous as well. Why don’t you implement the ‘normal’ behaviour from the start, and make it as lean and mean as possible? I guess the only reason you execute these Apache hacks is because there is no easy alternative… Doing it ‘the right way’ from the start, will force you to make the alternative easier to execute. And it will make the end result more fault-proof, because the deployment process itself has been tested (and executed) multiple times.

I agree that backups are a safety net, but they’re just that. A net that prevents you from getting hurt. But it doesn’t prevent the failure of the show A website that’s down for 30 minutes right after the (widely announced) go-live, because one forgets to change a setting in a configation file, is hurt.

Above that the dataset we’re working with can in no way be compared to a real dataset. Now we have about 20 entries in each module. The live site will presumably hold 2500K+ results per module (at launch). Once we’re in the final stages towards the first release, we’ll revert to our normal behavior: develop locally, commit changes to prerelease version of the site (to which the client has access to) and – if needed – modify online DB schema & upload new files to online version.

Could you elaborate on what exactly fired back? Can’t think of anything right away where we don’t have 3 (both on- and off-site) copies of. Above that all files (except for the useruploads, hence the goal of this article) are stored in the SVN repository, which gets backed up by Netlash’s hostingpartner (viz. Openminds).

@Dieter: aha, need to check that one … but is there a Mac alternative for my colleagues?

SQLYog offers an structure synchronization tool and a data sync tool. Never been easier/faster!

@Bramus! It’s not only about Tijs’ password, of course. Do the test: take a new machine (even with your favorite IDE and everything installed), and try to get the project running on it. Note down the number of times you said ‘oh, looks like I forgot to do that tiny, very easy to do thingy. And now _that_ little thingy. And now …’ Really. Not in your mind, but for real.

Oh – and a developer’s computer (something somebody is really working on, and doing experiments on) is not a substitute for a development server.

Don’t understand me wrong: I’ve _been_ in your situation. And I’ve taken the _same_ decisions. And it _has_ fired back at me