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

В чем смысл каскадирования ?
Если рабочих хранилищь несколько, как актуализировать данные соседних групп разработки между собой ?
Централизованное хранилище и сделано для того чтобы не думать как решать коллизии, а чтобы они не возникали.
И самый главный вопрос как использовать то чего не предусмотрено механизмами платформы?

Мы используем два хранилища. Одно хранилище обновления[release] (из него в скором времени файлы поставки стряпать будем для рабочей базы), второе хранилище разработки[trunk]. В первом только годный, православный и протестированный код, во втором, что угодно - хоть деление на ноль.

В trunk помещаем сколько угодно раз. Обязательно помещать в двух случаях - передача кода на тестирование, помещение в release.

Есть регламент, по которому захваты в обоих хранилищах обязаны совпадать за двумя исключениями:
1. новые объекты - они есть только в trunk
2. при удалении/переименовании реквизитов объектов (или самих объектов) иногда требуется захватить дополнительные роли, чтобы конфигуратор почистил ссылки. В этом случае дополнительные роли захватываются только в trunk, если помещение в release не планируется

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

Это называется ветки, бранчи, branch ... Переходи на 8.3 там можно использовать нормальные системы версионного контроля.

(3) получит внушение. За систематическое нарушение возможна различной тяжести любятина в зависимости от злонамеренности и последствий. Но пока прецедентов не было. Ведущие специалисты и начальство на регулярной основе контролируют ситуацию в этом плане.
(4) ну, как можно... там зачатки возможностей

(5) эээ, а чего там не хватает?

(6) встроенной возможности ветвлений и слияний безо всяких там выгрузок/загрузок в другие SCMы

(6) Посмотри, например, как делалось автоматическое накатывание своих изменений на типовую при смене релиза типовой в 7.7 + gcomp

(7) т.е. основная претензия отсутствие "встроенной" ?
(8) пока вижу только одну проблему с переименованиями объектов конфигурации, другие dvcs с этим не разберутся.

(9) да, но из этого вытекает херова туча сложностей:
1. Переименования объектов порождают геморрой
2. При создании ветки хранилища нужно дублировать учетные записи
3. Слияние ветвей - полностью рукопашный процесс, поверед бай копипаста. Просто потому, что, когда модуль изменен в начале и в конце, слить автоматически 1С его не может
4. еще может что есть - не задумывался.

(10) по факту повторить весь функционал git/bzr/hg/svn/fossil , но все эти SCM под GPL выпускаются.
ИМХО: 1с проще выгрузку/загрузку сделать, чем писать нормальную систему контроля версий.
Думаю 3 пункт, как раз бы и стал проще с помощью выгрузки/загрузки конфигурации.

Так, харе обсуждать возможности 8.3 и сторонних scm.
Да, очень жаль, что 1С не имеет продвинутых средств работы с хранилищами конфигураций и работы одновременно с несколькими хранилищами, синхронизации и слияния версий; создания и сохранения черновых версий разработок и т.п. Этого нет.

У меня потребность - что-то типа как написано в (2).
Мне нужно организовать как-минимум двухуровневую структуру хранения и передачи конфигурации.
1. Уровень - для проведения общей сборки решения (от разных, территориально распределённых групп) и проведения финального тестирования и помещения в рабочую базу данных
2. Уровень - для проведения рабочего процесса версионирования, передачи "не до конца готового кода" между программистами и группами.
Мне нужно проработать вопросы организации взаимодействия между этими хранилищами.

Особенно мне интересен практический вопрос синхронизации данных между хранилищами (вертикальными и горизонтальными) - как это эффективнее всего организовать?

Под коллизиями я понимал в первую очередь следующее: когда какой-либо объект захвачен в какой-либо ещё не законченной разработке, а он нужен для другой разработки (скажем, более срочной), которую может делать как этот, так и другой разработчик - как это наиболее эффективно разрулить при использовании каскадных хранилищ?

(12) так тебе уже расписали все в (2) .
1. это хранилище release
2. trunk

Синхронизация : из trunk выгрузи cf и объединяй с release.
Под коллизиями : хватай поменьше, коммить почаще, готовься к разрастанию хранилища как на дрожжах . Если надо одного разраба подвинуть, что бы другой сделал, то первый сохраняет отдельно cf, освобождает объекты, второй усердно делает, коммитит, первый забирает изменения, захватывает объекты и пытаеться смержить с сохраненным cf.

(13)Мне просто хотелось бы поподробнее из конкретных практик использования получить информацию. Особенно о регламентах захвата объектов и синхронизации версий каскадных хранилищ.
Когда оно одно - то тут боле мене всё ясно. А когда их несколько -  то тут свободы действий больше.
И очень интересно как работают удалённые группы программистов, работающие с одним проектом.

(14) ну я как Лефмихалыч@ отделом не руковожу, но от удаленщиков доработки сводил в рабочую базу. У меня регламент таков:
1. Хранилище release - из него делается поставка, обновления и рассылается на узлы.
2. Хранилище test - cюда приходят все доработки, после тестирования и комманды фас, из test выгружаем cf и загружаем в release. Release - практически всегда захватывается полностью.
3. trunk - используется или bzr или хранилище конфигурации (по желанию). Тут основные коммиты, коммиты, баги, фичи. Если необходимо оттестить какую либо функциональность то тут сразу и тестится.
В test захватываем и освобождаем сразу, коммиты только явно не ломающие функциональность (здесь самая большая проблема по захвату, но решается как в (13) описывал).
Удаленщики сделали, закоммитили в bzr, отправили в центр, там забрали cf и накатили на test. (удаленщики перед этим забрали cf из test, смержились и только потом отпарвляют в центр).

Вот, так. Ручной работы все равно много, где возможно применяю пакетные выгрузки.

+(15) задачки в redmine.

(15) Так, нужно осмыслить...
А что такое bzr и trunk, redmine?
"Release - практически всегда захватывается полностью" - а нет общего консолидированного учета объектов, которые находятся в работе у различных групп программистов? И, соответственно, общего контроля захвата (чтобы разные программисты из разных групп не брали одновременно объекты в работу)? И какова ключевая роль release по сравнению с test (ведь в test можно подготавливать конченый релиз, затем выгружать его в cf и передавать его сразу в рабочую базу)

общего контроля захвата - это бессмысленно, во всяком случаи у меня, т.к. может меняться в день несколько раз. Хочу уйти от выкатывания программистом раз в 2 недели тонны кода, n изменений (для хранилища это проще, не так тормозит, для понимания нет).
trunk -> test ->release . Так просто исторически сложилось, т.е. release это для поставки и там красивая история. test - в принципе тоже красивая история, только вот может разбавляться "исправление ошибок" и т.д. В принципе test выполняет функции release (но как говорил исторически так).

Общего контроля захвата нет, решается разрешением конфликтов программистами на местах (pull, merge, push), в случаи изменения метаданных создается задача в redmine со специальным статусом.

redmine - http://www.redmine.org/
trunk - текущая ветка разработчика (толи хранилище, толи DVCS какой нибудь).

(13) У нас так.
1. В случае, когда оба программиста работают по не связанным задачам и разработку первого надо приостановить:
  Первый отпускает в release и коммитит в trunk.
  Второй захватывает в release, захватывает в trunk. Накатывает на trunk версию объектов из release, чтобы затереть изменения первого.
  Далее сбора теста, тестирование коммит в release, первому возвращается объект.
2. В случае, когда задачи связаны и изменения можно объединить:
  Первый отпускает в release и коммитит в trunk.
  Второй захватывает в release, захватывает в trunk. Делает свои изменения и помещает в trunk.
  Либо передача обратно первому, либо тестирование и внедрение.