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.

How come some posters have white space between the line with their name on it and their tagline, and others don't? And how can I get rid of mine?

/me puts up hand.

(But, dude, you closed the "tag". Were you taking it down?)

you closed the "tag"

Ah, the innocence of youth. I mean I know you're joking, and all.

What (is this Natter?) is the word for a joke made using an interface convention you know won't work, but other people will recognise from another application? See also "I think you're a moron^H^H^H^H^H^H^H mistaken".

Actually, CVS doesn't work that way. Everyone can make changes to the same files at the same time. It's just when you try to check those files back in that you learn that someone else has been there before you.

Usually, though, CVS can merge your changes and the other person's changed automatically. It does by looking at the changes you made to the base version and the changes the other guy made to that same base version. Unless you're changing the same lines, there's mergey goodness.

Assuming I had a test setup on my Mac, here's how I would work:

Update from CVS to my machine, getting the latest changes.

Try them out, make sure it's all working on my machine.

Make my changes locally, testing as I go.

Update again, just in case someone has changed things in CVS while I was working. If the changes conflict, work out the conflicts locally.

Test one more time.

If we were using a ReleaseNotes file, this is when I'd write my release note, listing the files I changed and why.

Check in my changes. CVS calls this process committing. Heh.

That's the basic idea. There needs to be a little more refinement, for example, to come up with a way that we offically bless a set of sources in CVS as being the next Phoenix and move them over to production.

Ah, the innocence of youth. I mean I know you're joking, and all.

What what what? How is this....

going to AIM now.

Thanks for the links. I'll start playing around with that this weekend.

Looks like the MySQL guys are taking over distribution of the Mac OS X versions.