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.

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?

Lyra, as far as I can figure out, this is caused when the single space after "Mark" on the line above the tagline wraps, and the word "Mark" itself does not. The best way to fix it is to change the size of your browser window.

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

That's probably good. Now people can stop being snotty about the version that Apple provides.

Hey by the way, the lastest version of PHP doesn't pass variables from the query string to the page by default. It's turned off on a default install and you have to turn it on in a php.ini file.

Rob, I thought there was a lock function that could prevent others from checking out a file?

There is, I think, but I've never seen it used. It just isn't necessary, and on large projects could make it hard to get any work done. It would be impossible to get a lock on all the files you wanted to change.

Yikes. I'm kinda pro it, because I need confidence that I'm the only one editing a class at a time.

If it's one class per file, that can sorta work, assuming two people never need to work on different parts of the same class.

If there are multiple classes in a single file, exclusive access won't work very well at all.

And locking a single file doesn't help if I check in changes to a different file that your changes depend on. You still can't check in yourself until you merge with my changes and resolve any conflicts.

If colliding on the very same area of code is a concern, we should use the mailing list to announce the areas we're actively working on. That way we can all avoid making big changes to the same area at the same time.

It's one class per file, yes. And they're mostly independent, save thread and post. That's where my worry is. That and the basis of the page template -- those are where mutually buggering changes are most likely.

Well, CVS prevents mutually buggering changes from being committed. You can't check in until your local copy is up-to-date with the repository.

Here's how it works:

I have showthread.php;1.3 on my Mac and I've edited it. You then commit a change, making the current version 1.4. If I tried to commit my changed, CVS would mock me with "up-to-date check failed for showthread.php;1.3".

After I wept bitter tears, I would use cvs update to update my local copies. CVS would merge your changes (diff between 1.3 and 1.4) into my local copy. Unless we had edited the exact same lines of code, this would happen automagically. If we had edited the same lines, cvs would make it look like this:

>>>>>>>> showthread.php 1.4

>>>>>>>>>

>>>>>>>>>

I would then have to figure out how to resolve our conflict. Usually it's obvious.

Now, one hitch in this is that I could check in some files before I failed the up-to-date check on showthread.php. This is the reason you always want to update your local copy right before you check in. That way you don't half-way check in some changes and then have to quickly resolve conflicts to check in fully.