All of our PL/SQL , Schema Creation scripts, update scripts , system and test data scripts are all version controlled using CVS. The best way we have found to make sure all developers save the actual PL/SQL files is to enforce unit testsing in all our tiers and run a continous build process using Cruise Control which builds the database from scrach every 2 hours or so then runs all unit tests against them.
If someone has just been compiling their pl/sql on their local database build, it won't appear in our Cruise Control database and at some point a unit test is is going to fail.
Each team also has thier own database which they can rebuild from scratch and are encouraged to do this every week or so. Again this would highlight that there is a package missing and the rest of the team will start making a fuss to the DB programmer saying that their code has stopped working.
If by some chance or review process hasn't worked an there have been no unit tests written in any tier that will highlight there is a missing package or the team database has never been rebuilt we have a pre-testing QA that checks that the code written matches the requirements. This again builds the databse from scratch, unit tests are written and a run through the new functionality is done. This will catch out any db programmers who do not save and check their pl/sql into CVS.
It should also be noted that we use iterative development and we run through the development cycle every 3 weeks and so have a new test build every 3 weeks. So any mistakes can be easily found and fixed. We can build our whole database to any version in the past right from it's first version.
We have yet to have any problems with our PL/SQL source control but i would echo the statements made by others by saying that it is very , very important to record all changes, who did them, when and why. The database schema will probably outlive all the other tiers in a system so it pays to keep a track of what has changed.
Hope that provides some pointers.