I'm guessing that since coding Phoenix will be a spare-time only activity for all of us, we won't tend to collide on the test server.

How CVS performance look?

I was futzing with it on Buffistas.org, but I'm stuck at authentication methods. And I don't think there's any advantage to doing it there, if Karl doesn't mind hosting -- at least not to wait on me to work stuff out.

One advantage would be being able to check out directly into the test area, as opposed to having to FTP stuff to the server.

Can you run pserver on the test server?

Hmm. Don't know. How does that work client-wise?

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.