cvs pserver access lets clients have their own accounts and passwords for CVS without having a regular account on the box. All the CVS clients I've seen support it.

You'd still need to log into the test server to install the sources for testing, though, but it should be faster.

For example, you could create a branch tag, make your changes, check in the change on the branch, then check out that branch on the server for testing. We could even write a script to automate the checking out of the branch on the server for testing.

Is there some sort of changelog for version control as well?

When you check in to CVS, you're asked to enter a description of the changes for each file you modify. Those change descriptions can be viewed.

In some projects I've worked on we've also kept a central release notes file, where you list all the files changed in a single checkin and describe the intent of the overall change. I find that more useful then the descriptions on each file.

I nominate Rob as CVS expert.

I nominate me as not having a clue.

I suspect that the buffistas.org cvs setup is a bit hamstrung by limited rights and me not knowing the server side of cvs very well.

But Karl's setup works just fine. We need a methodology to wrap around it.

Is the test server the same machine as the production server?

Yup. Subdomain of.

Can I have a round of hands volunteering for devish duties? I want to set up a mailing list.

/me puts up hand.

I'm hoping I can get a fake phoenix running on my Mac. That might help.

I'm not sure this is the sensible way to work on code, because of the difficulty of keeping it updated, which is the whole point of CVS I guess. But let me know if you want links for getting PHP and MySQL set up on OS X. I've just done it three times on three different machines.

Can someone explain what CVS is for the dummies? I've got a Mac CVS client, but I'm just looking at the menus and going "huh?" at the moment.

If, for instance, Rob had his own dummy board, would CVS be some way of him synching his code with the real board code every time a line got changed in a script?

But let me know if you want links for getting PHP and MySQL set up on OS X.

I would, thanks.

If, for instance, Rob had his own dummy board, would CVS be some way of him synching his code with the real board code every time a line got changed in a script?

Yep. From [link]

CVS is a version control system. Using it, you can record the history of your source files.

For example, bugs sometimes creep in when software is modified, and you might not detect the bug until a long time after you make the modification. With CVS, you can easily retrieve old versions to see exactly which change caused the bug. This can sometimes be a big help.

You could of course save every version of every file you have ever created. This would however waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions.

CVS also helps you if you are part of a group of people working on the same project. It is all too easy to overwrite each others' changes unless you are extremely careful. Some editors, like GNU Emacs, try to make sure that the same file is never modified by two people at the same time. Unfortunately, if someone is using another editor, that safeguard will not work. CVS solves this problem by insulating the different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.

Thanks Rob.

That "Every developer works in his own directory" -- what are the practical applications of that? Apart from all developers being boys not girls I mean. It doesn't solve the problem of people working on a test site being able to break it, does it?

Oh, and for PHP and MySQL installation onto OS X, the best stuff I've found is here: [link] though of course just as I post that, the guy's server appears to be down.

Edit:

This is a nice article to follow on the OS X setups, though it also recommends that Swiss guy's package, so if he's down, same problem.

And hidden away in a series of articles which say they're only about Apache, some really good stuff from O'Reilly.

It solves it in that I know what you're working on, and I can prevent you from checking out the files I have. So in that sense, we won't trample on each other.