Есть проект, в котором есть база данных, которая есть Oracle.
В этом проекте используются вызовы множества процедур базы данных.
Эти процедуры скомпонованы в пакеты по их функциональной принадлежности (пакеты взаимодействия между БД, пакеты для отдельных клиентов, пакеты для web клиентов итп.).
Разработку этих функций ведут разные люди, в разных местах.
Процедуры и функции пишут используя PL/SQL Developer прямо в базе.
Не смотря на то, что БД несколько, случается так, что несколько разработчиков одновременно ковыряются в одном пакете, одной и той-же тестовой БД. Естественно, кто последний скомпилил, тот и молодец. А тот, кто не последний часть своей работы потерял.

Вопрос, существуют ли способы совместной работы нескольких разработчиков в одном пакете? Черт с ней с тестовой БД, пусть там что-то теряется. Допустим, каждый разработчик сохраняет свои изменения, т.е. DDL пакета со своими последними изменениями, пусть также он знает, какие процедуры он изменил или добавил, существуют ли какие-либо утилиты, которые позволяли бы создавать патч пакета БД?
Т.е. у меня есть DDL процедур, которые я изменил, я это скармливаю такой утилите, а она делает соответствующие изменения в пакете рабочей БД не затрагивая другие процедуры?

http://notes.rudomilov.ru/2007/01/30/stavi...ion-za-5-minut/
http://mydebianblog.blogspot.com/2008/06/subversion.html

Вы драматизируете. В проекте, естественно, используется SVN. Иначе никак.
Только как его использовать для работы с БД?

Да, я знаю, что для девелопера есть плагины SVN, только они ничего, кроме запуска SVNовских функций прямо из оболочки, не предлагают.

Вопрос в том, как свести отдельные изменения в один пакет?
Поддерживать исходники DDL в SVN? Это тяжеловато и от косяков не спасает.

Может использовать отдельные тестовые пакеты, потом переносить изменения в рабочие? Опять  же, если это все делать вручную, то это опять источник косяков.

Вопрос о совместной работе именно для разработки пакетов БД.
Или все так и мучаются?

как же вы его используете если у вас стоит такая проблема?!


так же как и для всего остального:
1) забрал актуальную версию из репозитория.
2) исправил код, скомпилил, протестил, сохранил.
3) загрузил опять в рапозиторий.

Для других вещей. Не для БД.




Ну наверно так и придется. Хотя нужно бы всего немного добавить:
1. Возможность залочить объект на момент писания/тестирования (надо будет присмотреться к SQL Navigator)
Или, как вариант, создание тестовой копии объекта.
2. Вменяемый мержинг при изменении объекта двумя (и более) разными разработчиками.

Залочить объект в SVN возможно.



Что значит вменяемый?


И вообще, не понятно в чем вопрос. Для остальных языков как-то люди работают коллективно и ничего. Что такого особенного в PL/SQL? Проблема будет только в DDL для модификации базы. Вот тут надо подумать как это организовать.

В SVN - да. В базе - нет. Просто возникает ситуация, когда два-три отдельных человека, что-то делают, потом одновременно (почти) компилят, потом долго тупят, почему все не работает, потом орут друг на друга на всю аську, потом, в конце концов договариваются, кто крайний. 



Вменяемый - это я хочу такую значит штуку, чтобы например в пакете есть процедуры А, Б, В, Г, Д. Я поковырял пакет, исправил процедуры А->А', Б->Б' и добавил Е. Закомитил.
При этом "другой я", в то же время, поковырял процедуру Г-Г' и добавил Ж. Закомитил.
При этом "третий я" после апдейта получил А', Б', В, Г', Д, Е, Ж. И чтобы второму я не приходилось вручную сводить это в одну файлу.
Аналогично хотелось бы и в DDL таблиц, секвенсов, видов и т.д. иметь мерджинг, который не тупо сводит и сравнивает тексты, а учитывает особенности языка.

При этом для отдельного скрипта отдельной процедуры SVN отлично подходит. Но когда касается пакетов, схем, тогда все ручками.

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

Вообще, если честно, этот проект изначально сделан так, чтобы было максимально неудобно. Например, по моему, стоило бы разнести разные функции для разных подсистем по разным пакетам и в такую проблему просто не упираться. Ну да ладно.

Почему два человека одновремеено работают надо одим блоком? Почему они одновременно компилят? Что значит орать, друг на друга, и выяснять кто крайний? 

Если у вас такая ситуация возникает, то надо немдленно гнать в шею вашего менеджера проекта и нанять компетентного специалиста.

Вопрос не имеет отношения к базам данных - это вопрос управления.  

Простите, если грубо, но если хотите зарабатывать умейте организовывать процесс. Даже SVN в некомпетентных руках  превращается в помойку.

Добавлено @ 20:49

Каждую процедуру храните отдельно + makefile для сборки пакета, затем вытащили ветку, запустили make  и он вам всё собрал и скомпилил. 

Это сообщение отредактировал(а) ToshaCh - 20.10.2008, 20:50

В данном случае, проблема в головах. Какого лешего, они одновременно компилят? Один залочил файл и работает с пакетом, компилит, отлаживает и т.п. Остальные в это время курят. Закончил - закомитил и разлочил файл, и тогда следующий начинает свои эксперименты.



Уж не знаю, чем вас так напугал мержинг. Если менялись разные процедуры, то мержинг и на автомате пройдет нормально, при желании его можно и руками контролировать. Да и сам мержинг это элементарная процедура (если конечно менялись независимые части пакета). Главное держите все объявления пакетов, их тел и т.п. в отдельных файлах и все будет хорошо.



Вы по моему сами не понимаете чего хотите. Для всех остальных языков, все обходятся и без синтаксического анализа, а вот для DDL, он обязательно нужен.
Что вы вообще от него хотите? Чтобы если Вася добавил в таблицу поле А, а Петя поле Б, то система сгенерировала скрипт который бы добавлял оба этих поля? 




А вообще я согласен с ToshaCh, у вас просто плохо организованна совместная разработка, и технологии тут ни при чем. У вас не согласованны действия разработчиков, и вы хотите, чтобы техника делала это за вас.

ToshaCh, - чертовски прав . Эффективный менеджмент, знаете-ли .
Просто знаете, когда оказываешься в такой среде эффективного менеджмента, остается надеяться на чудо, что-ли. А их, чудеса, как на зло все разобрали.
Спасибо за ответы, они к сожалению, подтверждают мою изначальную позицию и противоречат настрою руководства  (ну должна же где-то быть кнопка "решить все вопросы").
Спасибо.