Соответствующее дополнение можно найти по адресу http://plsqldev-svn-plugin.tigris.org/

Установка.
Установить последнюю версию клиента TortoiseSVN.
Установить последнюю версию клиента командной строки CollabNet Subversion Command-Line Client из http://www.collab.net/downloads/subversion (опционально, только для использования функции rename).
Скачать и установить плагин из http://plsqldev-svn-plugin.tigris.org/servlets/ProjectDocumentList
Рестартовать PL/SQL Developer.

1. Делаем checkout в директорию на диске.
2. в PL/SQL Developere -> Open project - нужно указать директорию, куда выложили файлы.
3. Дальше в контекстном меню будут доступны все команды. Стандартная цепочка для повседневной работы: открываем любой файл, делаем update-lock- правим - commit
4. Также можно вытащить кнопки SVN на тулбар, но они будут сканировать все директории проекта, что не всегда удобно.

Черт, не подумал - с Subversion есть опыт работы? Если нет - то сначала курить маны, потом настроить свой svn сервер или взять доступный в сети, например Google Code(http://code.google.com/intl/ru-RU/projecthosting/) или Assembla(http://assembla.com), экспортнуть туда свой проект и начинать юзать.

cinyx, если же командной работы не требуется, а нужно просто сохранять различные версии исходников, то лучше не париться с плагинами и Subversion, а просто поставить DropBox - и будешь иметь историю версию, которая автоматом сама синхронизируется, когда ты сохраняешь файл.

cinyx, базу сливать не надо, надо сливать исходники. Как это выглядит у меня (да и у многих знакомых):
в корне репозитория три папки, trunk - текущая разработка, tags - релизы, brunches - всякие эксперименты.
в папке trunk:
data - содержимое справочников
db_objects - исходники объектов.
в db_objects:
packages
tables
types
views и т.д.
дальше еще один (или несколько) уровень - модули (по логике).
Есть соглашения по названию - например тело пакета сохраняется в файл с такой маской: имя_пакета.body.sql и т.д.

Первоначальный экспорт исходников делали не то скриптом, не то из uml-генерилки, не помню.
Далее обычный цикл такой, разработчик перед началом работы делает апдейт файлов - подтягивает последние версии. Далее блокирует те файлы, которые ему нужно изменить (svn lock), изменяет, поверяет и делает коммит (svn commit). Вот простейшая схема работы. Можно также делать слияния, ответвления, возвращаться к прошлой версии - все эти схемы подробно описаны в доке (есть русский перевод).

Ну у всех по разному. Я еще ни у кого не видел прямой связки SVN->Патч. Ты же понимаешь, что для каждого типа объектов - своя обработка. Если изменен пакет - достаточно вытащить исходник из репозитария и передать в виде параметра sqlplus, другие объекты требуют предварительный drop, с данными если без внешних ключей проще - достаточно поставить в начале скрипта truncate и т.д. В моей компании для патчей используется самописная система, которая накатывает их на эталон, при этом номера патчей связываются с номерами SVN-ревизий и номерами тикетов, но сами патчи мы готовим вручную. Есть идея сделать что-то типа сравнения объектов из PL/SQL Developer, но пока никто за это не взялся.

VCS - интерфейс к системам, которые поддерживают Microsoft's SCC Interface Specification. SVN в их число не входит. SCC насколько я помню - это система контроля версий для Visual Studio, со всеми присущими MS плюсами и минусами (работает только на родных осях, платные лицензии и т.д.).
SVN - open source, нормально работает на многих осях, бесплатен и прост в освоении.
Вот как-то так.
-

Пока не освоились с командной строкой - поставьте TortoiseSVN. При таком коммите в директории будут три файла: исходник, и две версии с конфликтом. Файл можно подправить - уладить конфликт.
Вообще, зайдите на сайт TortoiseSVN, там есть подробный хелп на русском и по настройке и по повседневной работе.

Версионный гуру
Очень просто. Каждому разработчику - своя датабаза для тренировок. Ну или схема.

Улыбнуло - представил своих коллег, тренирующихся на отдельных базах.