Меня интересует такой вопрос. Никак не могу найти одной вещи. Может я постановку задачи себе как-то неправильно делаю?
Задача.
1. Есть несколько программистов, которые работают над одной конфой.
2. Работают каждый над своим функционалом. Обновляют с разной периодичностью (рабочую БД)
3. Функционал хоть и разный, но зачастую использует одни и те же субъекты конфы (документы, справ. и т.д.)

Нужно видеть (парсить изменения), какие субъекты затрагивали изменения каждого программера  - без того, чтобы заглядывать в код этих субъектов.
Т.е. создать некую модель, в которой описаны субъекты конфы во взаимосвязи с бизнес-процессами (которые автоматизируются). И рассматривать не просто версии (то, что дает cvs), а версии в привязке к тем субъектам, на которые оказано влияние в результате внесенных в данной версии изменений.

Пример.
При модификации модуля проведения дока "ХХХ" был внесен код типа:
...
УстановитьРеквизитСправочника(ТекЭл,"Кво",ТекКво,ДатаДок);
...

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

Проблема в том, чтобы корректно сливать изменения между собой (интервал изменений в раб. БД может быть месяц). Чтобы видеть причину проблем. Ведь они часто проявляются не сразу после обновления. И тогда найти, где проблема все сложнее.
В то же время объединить конфы, в кот. внесено много изменений в одних и тех же объектах сложно - нужн понимать логику, которую закалдывали в те или иные изменения.
Пока что выручает KDifff.
По поводу примера не понял намек - можно "расчехлить"? Я попробую прояснить.

Добре.
Тогда такой вопрос.
Как все-таки объединить изменения конфигураций?
При том, что модифицироваться могут одни и те же субъекты конфы разными программерами?
А актуальность метаданных, с которыми каждый работает - разная.

fez писал(а) 10. Января 2008 :: 10:53:

Потому что над задачей нужно работать минимум месяц, для того, чтобы ее реализацию можно было бы добавить в раб. БД. К примеру, один занимается производством, другой - продажами. Они могут пересекаться по справочникам (их реквизитам, как то: "дата пр-ва серии" - меняется пр-вом, используется продажами).
Если разработчик производственного  модуля забудет рассказать, какой формат реквизита даты пр-ва серии и т.п. Просто процесс разработки у нас не поставлен (поставлен стихийно) и осн. проблема именно в том, что нет никакой согласованности в том, что кто делает (кроме укрупненного закрепления по участкам как я описал выше)

fez писал(а) 10. Января 2008 :: 10:53:

Тема для меня новая, но интересная. Пока руки не доходят, чтобы разобраться.
Но проблема, о которой мы говорим, не касается тестирования. Если я говорю здесь про баги, то только про те, которые тестирование не отлавливает (в бизнес-логике). Практика показывает, что не всегда удается сразу правильно разработать ТЗ. И, если по ходу приходится что-то менять (напр., тип реквизита или сделать его периодическим), то нужно знать, а где еще нужно поменять работу с этим реквизитом (хотя, конечно можно поиском по модулям, но так ведь не все отловишь и опять же при слиянии изменений нужно это как-то учесть. Кроме того, нужно ведь принять правильное решение по поводу того, что в принципе делать с этим реквизитом с учетом того, где он вообще используется в БД и как.

Спасибо.

fez писал(а) 10. Января 2008 :: 11:22:

А вот это я себе слабо представляю. Как автоматически (да хоть вручную) проверить, к примеру, что когда-то понадобится анализировать продажи в разрезе стран, если при постановке задачи анализа продаж такое даже в голову не приходило постановщику задачи. Ну или любой другой подобный пример.
fez писал(а) 10. Января 2008 :: 11:22:

Это правда. Согласен, что все такие изменения будут отлавливаться автоматическим тестированием метаданных после слияния изменений (если, конечно, тесты грамотно разработаны). Может быть это действительно решит все мои вопросы.
Хотя меня удивляет, почему никто до сих пор не сделал такую модель под 1С (о которой я писал в первом посте).

Не со всем согласен, но ход мысли мне понравился (по поводу работы с тестами).
Очень жаль (по поводу грамотной групповой разработки), но факт. Никогда не "доходят руки", чтобы наладить работу как следует.

анекдот иллюстративный! Зачот!