Пост-предостережение. Вот тут вот http://www.v8.1c.ru/overview/DeveloperGroupp.htm в разделе "Удаленная работа" совершенно бессовестно написано, что "Начиная с версии 8.1.11, с хранилищем конфигурации можно работать, используя не только общий сетевой ресурс, но и соединение по локальной сети (используя протокол tcp) и интернет-соединение (используя протокол http). В общем случае взаимодействие разработчиков с хранилищем конфигурации может выглядеть следующим образом:
http://www.v8.1c.ru/overview/images/remoteandnotremote.gif";

Так вот практика показала, что ТАК ДЕЛАТЬ НЕЛЬЗЯ строжайшим образом. Надысь мы убедились в этом самым плачевным образом.

Для целей упрощения предоставления доступа удаленным разработчикам, мы развернули службу сервера хранилища, которая "раздавала" тот же каталог хранилища, к которому штатные разработчики получают доступ через smb (или cifs ли - как там этого ч0рта зовут - я не силен в дробях), тось через файловую шару.
В принципе все работало более-менее хорошо, но не безглючно - откат версии хранилища иногда приводил службу сервера в нерабочее состояние с симптомами:
1. при попытке подключиться или обновиться платформа заявляет, что версия платформы не соответствует чему-то там ожидаемому (не помню точно)
2. в окне хранилища "Меню Конфигурация..Хранилище..Хранилище конфигурации" из метаданных отображался только корень, всего остального как бы нет и не было
Это легко и просто лечилось рестартом службы сервера хранилища и с этим мы жили.

Сегодня служба сервера (предположительно это она, т.к. ранее без нее с 2003-го года ни единого разрыва не было) угробила одно из хранилищ довольно хитрым образом: два разработчика умудрились поместить одни и те же объекты в разное время с ОДНИМ И ТЕМ ЖЕ номером версии. В результате симптомы такие:
1. При попытке открыти историю, получаем "Хранилище конфигурации повреждено"
2. Обновление конфигурации из хранилища убивает базу
3. chdbfl говорит, что есть рассогласование индекса и данных в таблицах VERSIONS и OBJECTS. Он вроде исправляет это, но хранилище все равно мертвое.
4. Tool_1cd-alpha при проверке индексов два раза ругается, что "запись за границей объекта" (я хрен его знает, что это).
5. При этом, если открыть хранилище, не подключаясь к нему, то все работает и даже историю любого объекта можно спокойно посмотреть, и даже cf выгрузить

Вот как это выглядит:
1. Хранилище конфигурации повреждено (спасибо, кэп!):
http://savepic.org/4434663.png
2. Два автора одной версии:
http://savepic.org/4435687.png
3. tool_1cd показывает, что оказывается в этой версии не 2 объекта, а аж 4, про которых в истории хранилища ни слова:
http://savepic.org/4432615.png
4. chdbfl
http://savepic.org/4437735.png

Методов борьбы не нашел, добавю хранилище из бэкапа...

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

ЗЫ Версия платформы 8.2.18.96

добавю = добываю

Сколько ты ведешь борьбу с хранилищем?

В годах....
Может - ну его, смирись.

это не борьба, это я с ним работаю, а оно со мной - нет...

(0) Схема красивая на картинке ;)

В чем проблема всегда использовать tcp подключение? Даже в локальной сети?

(6) о! это отдельная тема для лютой ненависти, полностью раскрытая автором в статье вот тут http://wiki.mista.ru/doku.php?id=1c:v8:admin:server_xranilischa_konfiguracii&s[]=хранилище#chto_daet_i_chego_ne_daet_server_xranilischa_1s

Проблема в том, что crsever однопроцессорный, а разработчиков у нас много. Нет, даже так МНОГО! В результате все стоят в очереди к одному процессору и матом ругаются совершенно справедливо. Был такой эксперимент. Эта служба не предназначена для коллективной разработки, она, как собственно честно и прямо сказано на сайте 1С, предназначена для предоставления доступа удаленным удаленщикам по протоколу tcp и http.

(5) ты про remoteandnotremote.gif? Ну там надо кавычку шлёпнуть - форум ошибся малость

(7) Пора переходить на 8.3 ? :) Там скоростя, там полет.

(9) эксперименты показали, что хранилище особых изменений не претерпело. Да и тяжелое наследие размером в 6 терабайт не дает...

(10) в svn или git перегонял с выгрузкой xml?

интересно скорость сравнить работы. Хотя наверное с учетом в среднем 5 минут на выгрузку в xml одной cf , то у тебя долгое время займет.

(11) даже и не думал об этом - нет смысла, т.к. процесс разработки через svn или git просто невозможен при нашем количестве программеров. У нас туева хуча коммитов в trunk в день и самих этих транков тоже не мало, т.к. информационных систем много. Я продумывал процесс. Это не возможно. Долгосрочное хранение - да, возможно, но на кол оно не нужно это долгосрочное хранение

мертворожденная фича - эта выгрузка в xml

и хранилище 8.3 тоже мертворожденное, поскольку так и осталось централизованным и на базе 1cd

Нечаянно нашел способ откатить битую версию. Итак, если у вас история, похожая на сабж, и при открытии общей истории хранилища конфигуратор ругается исчерпывающе точной формулировкой "Хранилище конфигурации повреждено". И при этом можно открыть историю любого объекта, то шанс на восстановление у вас таки есть и не малый.
Из формы истории объекта можно перейти (там менюшка одноименная) в общую историю хранилища. С разбегу это у вас не получится ("Хранилище повреждено", помните?). Для того, чтобы таки открыть общую историю из истории объекта, надо:
1. в форме истории объекта установить отбор по периоду, не включающему битую версию
2. В меню "перейти" формы истории объекта выбрать пункт "История хранилища":
http://savepic.org/4452905.png
И вот в этой форме общей истории уже можно откатить хранилище до здоровой версии.

Нашел случайно через 5 часов после восстановления из бэкапа. Блин блинский...

(16) ФИО прогов палишь.