Making the move to source control

Solution 1:

It's helpful to have everything versioned, even for designers. And if implemented well with good training, I think they'll find it more helpful than burdensome.

If you're just starting out, I'd strongly suggest using a distributed version control system like git or mercurial. This is the general trend in the world, and there are a lot of advantages. It's easy to work in a disconnected mode, with no network dependency and the ability to do private, unpolished work still under version control, checking everything in centrally when it's ready.

And, not to resort to appeals to authority or anything, but check out what Joel Spolsky has to say on the topic. (Choice quote: "Subversion = Leeches. Mercurial and Git = Antibiotics.") Among other things, he makes the interesting point that these new systems use a new mental model, different from traditional version control — which is why getting into this kind of approach from the beginning is a win.

Solution 2:

I would say put everything under version control. Once it all works, you can copy it to a tag which for most SCM systems does not require lots of disk space on the server.

As far as initial pitfalls go you should shouldn't have to worry much; commit everything to the server and if it's not correct you can shuffle it around and delete the extra stuff later. The only thing I would not commit is artifacts that are built from source, i.e., java code files belong in version control but not the compiled classes or entire ISOs / DVDs of "built from source" binaries.

Dev to production is easy, at every major milestone create a branch. The directory layout in the version control system usually looks something like:

/trunk/project /branches/project/version1 /branches/project/version2 /branches/project/version3

So let's say you find a bug in version 2 of the product, you navigate to that branch, fix it, and release version 2.1. All the while you are working on the /trunk/project folder for the new version 4 and it's up to you which features are merged backwards and forwards.

Don't let the SCM kool-aid drinkers fool you, there are very little functional differences between the popular version control systems out there, namely Subversion and Git. The most important thing for your team will be how well those servers integrate with your existing tools. I don't like WYSIWYGs either but it sure is nice to have eclipse-php or other IDEs that are compatible with the server.

Solution 3:

I'm a developer and have been involved in working as an IT admin before.

To answer your specific questions:

1) Yes, Version everything.

2) Suggest you set up a dummy version control repository and dummy project for people to learn on.

3) Tag the versions that get put into production. even the trials. Then you can always check out a specific version that someone is running.

I see you've tagged the question CVS.

My suggestion is to take a serious look at subversion instead, combined with TortoiseSVN which makes it very easy to use. There is also a TortoiseCVS as well.

I suggest you run an in-house tutorial on version control. I'll be surprised if your developers/designers haven't encountered this before. Tortoise just makes it very user friendly.

It can also be beneficial to install one of the web interfaces into cvs or subversion.

The reason I suggest subversion over CVS is that while CVS is very good, it has some serious design and implementation problems. The biggies for me were: 1) You can't version directories 2) Binary file handling is not too good as lots of things default to being text. 3) No atomic commits. 4) I recall it often messing up and leaving lock files around that I had to remove manually from the code store. There was room for corruption in doing this since your rm the lock files. 5) SSL support and managing users/passwords

Subversion basically fixes all of those problems are probably many others. It also has a lot of advanced features like externals (which I actually do use). And it's possibly to link the users/groups into active directory which you might find useful. At the time I used CVS that wasn't available. It might be now, I haven't checked.

Probably the biggest difference to get your head around svn in using it is that you don't create tags. Instead you create what appear to be copies where the project directory is copied to the Tags folder and given a name. Have a look in the documentation and you'll see what I mean. I know it looks weird but you get used to it.

This website might be of some benefit (although I can't vouch for it): Setting up a modular svn repository for php websites http://www.howtoforge.com/set-up-a-modular-svn-repository-for-php-websites