какие впечатления по сравнению с файловой версией?

стоит ставить или нет?

ставь. особенно если хранилище далеко, много разработчиков и/или нестабильная сеть.

много = больше одного

(0) Юзаем у одного клиента. Лет 5 уже работает без проблем.

Пользую с момента ее появления, в 8.1 или 8.2. Мне нравится, и случайно хранилище не снесешь и если что шифровальщик не зашифрует. По скорости ничего не скажу, но не тормозит.

(0) Предпосылка такая - служба работает с файлами хранилища *локально*, стало быть юзает виндовый кэш. Стало быть работает в несколько раз быстрее чем по сети

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

(6) вместо этого юзаете git?

с тех пор, как crserver стал многопроцессорным, его осмысленность сильно возросла. Но ожидать скачка производительности не стоит: в конечном итоге любая операция - это собрать дохера байтов из хранилища, передать дохера байтом клиенту, собрать дохера байтов из рабочей копии, преедать дохера байтов по сети серверу. Поверх всего этого действуют табличные блокировки.

Мое ИМХО вот тут http://wiki.mista.ru/doku.php?id=1c:v8:admin:server_xranilischa_konfiguracii
годы прошли, а ни хрена не поменялось в генеральном плане.

(6) а у вас платформа другая у разрабов чем рабочая и рабочая к хранилищу подключена?
Да вы рисковые ребята.

(5) Замеров не делал, но чисто субъективно работа через службу медленнее.
То есть, если даже сама служба с файлами работает и быстрее, то потеря происходит видимо при работе по сети при обмене "служба сервера хранилища - клиент".

на 8.2 был прецедент, когда crserver двум разным разработчикам выдал один и тот же номер версии при коммите.
Но, чтобы это воспроизвести, надо 30+ одновременных разработчиков и чтобы елдошили в поте лица.

(0) Юзаем. Работает великолепно.

(11) ну это как 30+ одновременных юзеров в файловой бухне

+ (12) Причем раньше работали через файловое. В сравнении, субъективно, через службу - быстрее.

еще в файловой нравилось бодаться с правами в сетевой шаре...

(0) Через службу медленней, но количество ошибок блокировки много меньше.
Если делать через http и есть удаленные разработчики, то нужно ставить бесконечные таймауты, что тоже не есть гут.

Работаем с версии 8.3. Все агонь.
1 раз заглючил локальный кэш хранилища на одном из компов разработки - снесли кэш и поехали дальше.

"то нужно ставить бесконечные таймауты, что тоже не есть гут."

эээ?

ююю

(16) Ненене накой такое извращение??

(7) Да если бы. Смотрели в его сторону, но там свои тараканы. Файловый вариант юзаем.
(9) Что есть - то есть. Тормоза придумали трУсы :-) Не в рабочей же платформу тестировать?

(21) с файловым имел неприятный опыт при кратковременном пропадании сети

(13) именно!
(22) хранилище устроено так, что, если ты им активно пользуешься, то проблемы с ним у тебя будут при любом варианте развертывания.

(22) А есть данные, что серверный вариант все делает "транзакционно"? Это же может быть просто эмулятор SMB и так же сетевая ошибка может вызвать крах хранилища. В документации ничего нет.

(24) Такое ощущение, что это не может быть эмулятором SMB
Пример: У нас была удалённая ИБ (продуктив). Хранилище находилось отдельно. Обновление продуктива из файлового хранилища занимало 40 минут по достаточно широкому каналу. После перехода на хранилище TCP обновление занимало 3-5 минут.

(25) Ощущения они такие ощущения. Если бы 1С как-то расписало как это функциклирует или кто-то реверснул. А так вилами на воде писано.

(25) криво сеть настроена, к самому хранилищу отношение имеет посредственное;
у меня был случай с DFS: когда несколько разрабов к одному хранилищу через разные пути были подключены, один из которых по воле админов указывал DFS-репликацию. В результате между сеансами синхронизации DFS кто-то получал старую версию хранилища, кто-то терял обновления.
Переход на сервер хранилища эту проблему попросту исключил.

(27) Не думаю, что проблема была в нашей сети. Админы у нас крутые. Да и я им всю плешь выел этим вопросом. Ну и вроде как я может быть не уточнил: ИБ находилась на другом конце нашей необъятной Родины.
В итоге таки решение оказалось единственное: переход на TCP.

(11) У нас как-то давно при 3-х разработчиках один умудрился случайно или специально затереть изменения другого. Он просто работал дома не подключаясь к хранилищу, потом принёс конфигурацию на работу, захватил хранилище целиком и перенёс "свои" доработки.

(29) это не проблема хранилища. Это просто говнокодер этот хранилище не использовал

(29) Так ведь предыдущая версия в хранилище сохранилась, можно провести сравнение объединение.

(31) Да, но это произошло после того, как результат совместного труда отдали заказчику, т.к. "мой" участок был протестирован и никто не предполагал, что он исчезнет.
(30) Согласен, но после начала использования продукта  впечатление было, что все в белом, а я...

(29) Казалось бы причем тут Хранилище :-)

(33) Было бы логично со стороны хранилища дать какой-нибудь сигнал, что мол ты пытаешься откатить изменения там-то.

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

(34) Что значит откатить, если речь идёт об изменениях?

(35) ну хранилище должно было "смекнуть", что новые изменения по сути откатывают. Что у него "чуйки" нет чтоли?

(35) Хранилище анализирует изменения и сравнивает с предыдущими версиями и таким образом вычисляет, что такие-то изменение это откат к прошлому варианту и предупреждает. Т.к. для отката к предыдущей версии нужно было воспользоваться инструментами хранилища...
Если изменение уникально, значит это действительно изменение и оно принимается без вопросов.

(0) не заметил никакой разницы