Может кто подскажет, достаточно будет изменить максимальный ID или нужно еще какие-то нюансы учесть?

как-то поподробнее можно мысль развернуть?

(1) Я так понимаю вопрос, что при активной разработке конфигурации, постоянном сливании конфигураций нескольких разработчиков в одну, постоянно растут внутренние идентификаторы для новых объектов метаданных. Вот у меня недавно добавленный регистр имеет наименование RG133016. Надеюсь, что до RG999999 (восемь символов) еще долго, потому что больше уже вряд ли 1Ска даст.

я разбираю md разбирается gcomp-ом в результате в каталоге в том числе возникает файл ИдентификаторыКонфигурации.mdp
в котором содержится значение "Next ID"

Вопрос в следующем: если у меня это значение будет равно 10000, а у другого разработчика 11000, то исчезнет ли проблема идентификатора при создании новых объектов конфигурации, или необходимо учесть какие-то дополнительные особенности?

"я разбираю" - лишнее)

(2) о подскажи, пожалуйста, как у вас это устроено?)

а смысл собирать md через gcomp?
у нас только для логов кто что поменял SVN пользуется, а MD меняем штатно - через объединение
т.е. логика такая:
1. забираю по понедельникам свежий MD из центра
2. делаю загрузить в свою локальную версию
3. меняю что-то в локальной
4. объединяю свою версию с конфой для обновления (держу конфигуратор конфы для лбновления открытым)
5. Сохраняю конфу для изменения (конфигуратор открыт пока)
6. разбираю конфу для изменения gcomp (конфигуратор открыт пока)
7. заливаю изменения в svn (конфигуратор открыт пока)
8. закрываю конфигуратор конфы для изменения

(6) хм ... тоже вариант, псасибо

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

(6) п@#$%ц прости хоспади ... и нафига в этой схеме svn?!!

(8)вроде по русски написано "у нас только для логов кто что поменял SVN пользуется"

(6) А ничего, что при сравнить-объеденить ИДшники объектов метаданных могут измениться?

А набуя думать о внутренних ид?
Берешь тестовую, в нее заливаешь свое.
Если объекты пересеклись - думаем индивидуально.
Или вы там вчетвером крошите справочник номенклатуры?
Тогда в консерватории что-то нужно править...

(10) ну и что с того?

коллизии разруливаются на этапе объединения с конфой для изменения

(12) да не, ничего
если 1Ска грохнет вам справочник, документ или регистр - тогда задумаетесь

(14) с чего бы вдруг при объединении что-то там грохнется?

в тестовой возможно, но на то она и тестовая

(0),(3) у нас за сборку релизов отвечал один человек, думаю это хорошая практика, иначе бардак будет разобрать сложно.
ему слали свои изменения, он так же как вы через gcomp сливал.

(17) Если люди адекватные - могут сами заливать. Сборщик может не знать точно в каком месте какая запятая что значит (если разработка была долгой и мд у чела не совсем свежий).

(16) интересно, как вы отладку программного продукта ведете, если у вас тестовая регулярно остается без значительных кусков информации?

(17)
у нас непосредственно обновление делает один человек
Сборка финального релиза делается методом "забрался из репозитория и скомпилировал".
Просто нефиг в репозиторий заливать всякую недоделанную фигню.

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

(21) В этом и прелесть репозториев - 90% конфликтов решаются автоматически

ЗЫ участвовал в совместной разработке и до того, как познакомился с гкомпом и репозиториями.
Но после знакомства - нафиг-нафиг такое счастье.