Theory behind version control

Guys/girls,
I have been developing websites by myself for a few years and haven't really had the need for version control because I kept regular backups and I was the only person working on files. I would test locally on my own machine running Apache and then upload via FTP once the work was ready to roll out.

Now I work in a team of three and keeping on top of all the different versions is becoming more difficult. Each one of us has been working in the manner described above, and every now and then we will overwrite each others changes.

I am looking at whether version control is the answer. Having read the basics I wanted to make sure my understanding of version control (esp. CVS or Subversion) was correct. I get the impression that the version control software keeps all the files, plus information about the edits and editors, on a server. You check out the files, edit and then commit the changes. But the version control repository is not an actually working web server?? - it is just a place to store the files?? To make those changes work on a live server you would have to export the files from the version control repository and then upload them to the live webserver...?
Is my understanding correct?

Ideally the solution I wanted was to be able to check files out of a working web server and upload them again once edited, checking for conflicts etc. The way I understand version control is that it adds an extra step. It seems an inconvenience to export those changes and then to put them onto a live server.

Is my understanding correct? Is there a better solution? I have also heard of application installers, such as Phing, that make installing projects easier - would that be any use?

Many thanks in advance for your responses.
Andy

Version control is just one of the key elements of the "engineering" part of software development. You should never write the frist line of code without a good version control system. Yours was adequate for a single user but now you have exceeded its capabilities you should upgrade to something along the lines of CVS or SubVersion (IMHO).

Yes there's an extra step or two, but it allows for concurrent work to continue un-interrupted and facilitates coordination. You could have a change that needs to go to the web site emediately while your cohorts are working on changes that won't be ready until next month. You check-in your work, label it and then check out against that label. Test and if no errors upload to the web site. You note in your logs "Uploaded <label> YYYY/MM/DD fix bug #nnnn". Then you buddies are ready to check-in and they discover you've made some changes since they checked the code out, so they have to merge those changes into theirs and then the process repeats.

You could have several planned releases in progress at the same time, in various stages of development from code in progress to test/recode cycles and this allows you to keep track of the code state at each milestone and which milestones got shipped to your server.

your basic understanding is correct.

CVS and SVN generally do not have a concept of 'check out' a file, you get the latest version, make local changes, and then check them in. Some tools do use a checkout/lock model.

I can not imagine having more than one developer on a project without source control. I use it for all of my work, even solo projects.

The ability to easily look at code from last month is priceless.

These days I use SVN (aka subversion) as it installs on nearly any server and works on all known clients.

Its a little better than CVS, IMHO. But using any package is so much better than using none that any differences between packages is trivial.

For developers on Windows, TortoisSVN
http://tortoisesvn.tigris.org/
is highly valuable