Yes, this implementation would make reversion irreversable. I guess that might not be desirable although that's a better question for the clients than for me. I could implement a reversible reversion by creating a new version as a copy of the old one. That should be pretty easy to implement considering that the checkout routine will already need a cloning capability.

I think in this case my users really will want full versioning capabilities. The system they're using now has them and I think they've gotten pretty used to it. However, given what a pain this is to implement I think I can make a pretty strong argument that going with something simpler could save them a lot of money in development.

Thanks for the help,
-sam

You are probably better served by using PostgreSQL instead of MySQL. MySQL is not a very good database for a multiuser aplications (lack of decent locking, referential integrity, etc.). I know MySQL has come a long way since I last looked at a year or two ago (I think they may finally have referential integrity), but I still think it does even come close to PostgreSQL in terms of ACID compliance.

UPDATE: Apparently MySQL now has some weird form of row level locking for some table types.

Please read How MySQL Compares to PostgreSQL. They put it much better than I could ever hope to!

Aside from all the excelent reasons listed there I prefer MySQL for one more reason - it's fully implemented. Take a look at PostgreSQL's ALTER TABLE, DROP and VACUUM implementations sometime! I've had more headaches working on PostgreSQL for the past year than I ever got using MySQL.

-sam