Поделитесь, насколько это рабочий механизм.

ВСЕ

(0) Просто нет слов

Использую
Рабочий

Абсолютно не рабочий)

не встречал таких людей

И что сегодня не пятница

Никто не юзает... 8ка еще сырая совсем =))))

лучше у 1с все равно нет.

(0) Используй.
(2) Да ладно, бывает...если зоны ответственности по базам поделены, то особо оно и нафиг не надо :)
Вот когда  с конфой ежедневно работает сразу куча народа, тогда не обойтись.

ппц. Это азм и есмь разработки.

Спасибо 8.3, за предкамменты при захвате!

просто читаю, говорят, что много исчезают изменения, постоянно вываливается хранилище повреждено и т.д., естественно при работе с хранилищем в тестовом варианте, развернул тут у себя, все хорошо, вот и захотелось узнать поконкретнее, на что стоит обратить внимание

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

не записывай по сети рекурсивно корень в типовых :)

в остальном нормальдос.
бывает слетает хранилище (у меня не слетало).

да и перед уходом с работы не забывай отпустить корень - вдруг после тебя кто-то до ночи остается работать :)

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

(0) На текущем месте юзаем...до этого не юзал. Есть плюсы, есть минусы, но в целом впечатления положительные

Если ГноКодеры.Количество()>1 Тогда
   ИспользоватьХренилище=Истина;
КонецЕсли;

Главное - состав версий не меняй. Ну там объединения, откаты к версиям. А если меняешь, то обязательно бекап хранилища делай. У нас хранилище падало только из-за этого. Я даже как-то закономерность выявил. Кстати, бекап хранилища надо каждый день делать, не только перед изменением состава версий.

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

Ну и вот почитай http://wiki.mista.ru/doku.php?id=1c:v8:admin:server_xranilischa_konfiguracii

(0)Используем.

(0)Естественно. А куда без него?

(0) Использую на протяжении ~ 10 лет.
Если всё делать корректно, будет работать без глюков. Т.е., вполне рабочий механизм.

(19) Сервер хранилища не обязательно ставить. Без него даже быстрее получается.
И бэкапов хранилища вообще ни разу не делал... )

(23) А без бэкапов - ты смелый :)

(24) Мне бэкапов базы вполне достаточно.
Разработки ведутся в отдельной базе. Если хранилище вдруг навернется, из этой базы всё можно будет достать.

без хранилища разрабатывают только му***даки. Те же му***даки обычно бэкапов не делают и сразу херачат на продуктив свои поганые костыли

У меня вот вопрос - кто работает с архивом так, как рекомендует 1С?
Т.е. когда нужно держать целую кучу хранилищ.

(27) Тьфу... не с архивом, а с хранилищем :)

(27) я, например

(29) Насколько удобно? Или надо просто привыкнуть?
Куда деваете мелкие хранилища?
Сколько разработчиков одновременно работают над конечной конфигурацией?

(27) Делаем так иногда. Для некоторых задач поднимаем отдельное хранилище. Потом мержим.

(30) что значит "удобно"? По-другому просто не возможно, когда количество разработчиков хотя бы не маленькое, не говоря уж о большом.
Ну и для долгоиграющих разработок, которые могут тянуться не один релиз, "ветку" нужно делать в отдельном хранилище вне зависимости от количества разработчиков, чтобы не мешать в основном хранилище всякие экстренны задачи делать. Только в этом случае ветка должна ставиться на поддержку основного хранилища (что надо изменить - снимаешь с поддержки), чтобы потому репу не чесать, что там было изменено, что не было и какой была конфа на момент начала разработки

+(32) хотя понятно, работа с несколькими взаимосвязанными хранилищами - это сложнее, чем работа с одним или без хранилища вообще. Нужны стандарты и регламенты, чтобы люди понимали, что и как они разрабатывают, что отдают на тест и как потом мерджат. И за этим нужно следить по большому счету "руками", т.к. программно с хранилищем ни хрена толкового не сделаешь. Уныло и не просто, но без этого ад и погибель с выпуском патчей для патчей для патчей для патчей

(33) То, что регламент нужен - понятно.
Пока работаем с одним хранилищем по определенной схеме, но начинает напрягать сложность ведения длительных проектов.
Будет совсем не вмоготу, буду изучать предложения 1С :)

(26) Ой, какие мы умные.
А если в конторе один прог и то приходящий - на какой орган там хранилище?

(35) какая там разработка при таких условиях? Установка обновлений и "нам нужна обработка" - это не разработка. Это даже сопровождением не назвать

(36) Роль добавить бывает нужно. Добавить реквизит к объекту. Изменить доступность/видимость полей, элементов формы. Добавить подписок на проверки условий и т.д.
Да, это просто. Но это не может сделать простой пользователь, Это работа программиста.
Собственно мысль: при одном программисте и небольших изменениях возится с хранилищем нет смысла.

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

(38)+
простой пример

вызвали кодера и говорят - вы в прошлый раз были и все поломали, исправляй бесплатно - твой косяк

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

даже ради этих 2х пунктов точно стит юзать хранилище

Не использую, и не знаю что это

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

(37) технически это все действительно можно и без хранилища сделать, но так делают только отчаянные чудаки

Глючное УГ. Разрушается от каждого чиха. Линейная структура истории делает его практически бесполезным

так вот, невозможно создать хранилище из текущей базы. 1с-ка просто тупо валиться на 87% создания и все.
платформы - пофигу, что 8.3, что 8.2.

база ТиИ проходит успешно, все ок, никакого УРБД.

(46) выгрузи cf, загрузи его в новую пустую базу, создай хранилище на пустой, потом к хранилищу подключи базу.

только про бекапы не забудь :)

> выгрузи cf, загрузи его в новую пустую базу, создай хранилище на пустой, потом к хранилищу подключи базу.

не помогает. что-то с конфой, я так думаю.

кстати про глючность - да оно глючит, бывает. лично я при активной разработке примерно раз в пол года пересоздаю хранилище.

(48) если что-то с конфой то сф не загрузишь

(50) тогда я пас. cf-загружается и выгружается ок. dt - тоже.
а вот хранилище при создании падает.

база не типовая. ессно.

(27) можешь кинуть ссылку, где про это почитать?

Хранилище полезно даже при единственном разработчике

(43) Один сижу)) Я был у них в январе, второй раз в июне. Если печатную форму нужно: делаю внешней и шлю на мыло.
А так да, со всеми доводами согласен. Хранилище вещь нужная, полезная и работающая. Но бывают случаи, когда оно нафиг не нужно.

Серверное - плюс. Файловое - это не хранилище, а гемморой.

Но если разработчиков чуть больше чем дофига, и разработка - то по идее должна быть тестовое хранилище, и хранилище стабильный релиз.

Ну и не забываем регламент чистить кэши каждый день при выключении - а то мало ли.

(18)>У меня даже проверка стоит, чтоб пустых комментариев не было.
Поделись )

(25)>Разработки ведутся в отдельной базе.
т.е. отдельная программерская база подключена к Хранилищу, а рабочая - уже по факту периодически подключается?

(32)> Только в этом случае ветка должна ставиться на поддержку основного хранилища (что надо изменить - снимаешь с поддержки)
- где объекты снимаешь с поддержки для долговременных проектов - в Хранилище, в продакшн или где?

(37)>Собственно мысль: при одном программисте и небольших изменениях возится с хранилищем нет смысла.
- а через пару лет вообще никто не будет знать, что и когда и зачем там изменено?

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

(60)>Нет, рабочая база и базы разработчиков всегда подключены к одному хранилищу.
перекосов нет, рабочая не падает, когда от разработчика уже пришло изменение, а в продакшн по каким-то причинам не "вошло"?
Бывают случаи, когда при постоянном подключении к Хранилищу продакшн падает (бьется config).

(0) Механизму хранилища столько лет, сколько самой 8-ке. 8-ка до сих пор сырая. Делай вывод.

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

у нас логика такая - базы для разработки подключены к хранилищу, а вот живая обновляется сравнением/объединенм с храниилщем. Можно применять отдельными кусками + мониторинг применяемых изменений

(59) ни кто не будет знать, где вообще хранилище и какой пользователь :D

(64)>а вот живая обновляется сравнением/объединенм с храниилщем
т.е. продакшн вообще не подключена? Все через CF?

(65) не через CF. Есть функция сравнить/объединить с хранилищем.

(0) используем

Используем всегда. До 10 человек  в одном хранилище.
Плюс автообновление рабочей базы из хранилища ночью (небольшой скрипт).

(68) не опасно )?

В этом году пришлось 2 раза с нуля создавать хранилище - при добавлении версий на 100+ МБ начинает сильно тормозить. В 8.3 возможно будет лучше - там в отдельных файликах хранится.

Рабочая база подключена к хранилищу через логин только на чтение - доступно только обновление. Периодически обновляется. Программистов несколько.

(65) -> (66) . Удобно

Но есть какие-то проблемы с кэшем. Иногда изменения не доходят до адресата

(70) В 8.3. работа с tcp хранилищем субъективно быстрее. Вчера начали работать. Правда конфа пока небольшая, в основном объекты БСП.

Даже не слышал о таком, посты заинтриговали, буду узнавать.

(71)>Но есть какие-то проблемы с кэшем
Чистите каждую ночь? )
(70)>Рабочая база подключена к хранилищу через логин только на чтение
так все проблемы и есть при обновлении продакшн. Вернее, некорректном обновлении.
(70)>при добавлении версий на 100+ МБ начинает сильно тормозить
рекомендуют типовые обновления вносить раздельно: накатить на базу программиста (или даже пустую базу, без данных) - перенести в Хранилище. Ообновить продакшн из Хранилища. Однако тут надо каждое обновление так ставить - вдруг нужно данные переместить при удалении типовых объектов.

(74) >так все проблемы и есть при обновлении продакшн
После динамического обновления уже не страшно) Это чтобы случайно не захватить в рабочей, были случаи. Особых проблем не было, удобство и оперативность перевешивает, но при наличии распределенки ни то ни другое не советовал бы.

>рекомендуют типовые обновления вносить раздельно
База УПП переписанная, не обновляется. А если типовая на поддержке с небольшими и редкими изменениями, тут проще вообще без хранилища.

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

тупо за ВСЕ обновления должен отвечать один человек !!!
эта линия контроля очень много проблемм снимает.

(64) Мы только рабочую к хранилищу не подключаем. Оно не стоит, имхо.
Деалем финальный релиз, его проверяем и если все в порядке - делаем поставку (через механизм поддержки)

(76)>рабочую к хранилищу подключать не советую
и как вносить изменения?

(77)>делаем поставку (через механизм поддержки)
вы CFU делаете?! Не проще CF выгрузить и объединить?

(79) Поддержкой CF.
Сравнить-объединить - могут внутренние гуиды метаданных разъехаться. Тогда сделать тестовую и подключить ее к хранилищу может быть весьма трудоемко.

(80)>Поддержкой CF.
это как?

+ >могут внутренние гуиды метаданных разъехаться
если ГУИД будут разные - то при объединении с CF обновится на ГУИД из Хранилища (как изменение).

(80) можно и обьединением CF, отьехать может только в 2х случаях

1. прямом изменением в рабочей
2. удалении и пересоздании объекта в хранилище

оба случая следует исключать из работы по любому.

копия делается так
1. отключаем старую копию от хранилица
2. заливаем бекап
3. подключаем к хранилищу

(81) Либо при создании файла указываешь, что нужен CF, а не cfu (галочка - создать файл поставки) - он загружается стандартным способом.
Либо /CreateDistributionFiles -cffile
Недостаток - размер cf больше, чем cfu
Достоинство - можно сформировать архив, где всегда можно можно сравнить 2 произвольных релиза.