Хранилище конфигурации: не очевидные особенности групповой разработки

03.06.13

Разработка - Групповая разработка (Git, хранилище)

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

Введение

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

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

Базовый порядок работы

Итак, сначала вкратце опишу базовый порядок работы с хранилищем, который используем мы:

  • Рабочая база подключена к хранилищу;
  • Для каждого разработчика создается отдельная копия;
  • Пользователей хранилища мы называем по имени базы на 1с сервере. Пароль всегда стандартный и одинаковый. Это очень удобно. Совершенно не нужно помнить никаких логинов/паролей. Если ты заходишь в конфигуратор рабочей базы, то вводишь в логин имя рабочей, в копии - имена копий;
  • Рабочая база (желательно ежедневно) в ручном или автоматическом режиме обновляется из хранилища;
  • Если в течение дня пришлось что-то аврально исправлять, то можно внести исправление и в рабочей базе, но сразу поместить изменения в хранилище.

 

Особенности

Теперь перейдем к вещам, которые обязательно нужно помнить при работе с хранилищем. Многие из них достаточно очевидны. Однако есть и такие, которые мы “словили”.

Хочу обратить внимание, что основное “словили” заключается в особенностях ведения наших проектов, однако полагаю что для многих это также актуально. У нас есть несколько самописных систем, которые уже эксплуатируются, но также активно дорабатываются. В рабочие конфигурации внедряются новые подсистемы, затрагивающие достаточно большой функционал. При этом, как всегда, всем надо всё и быстро, и мы не можем себе позволить по полгода разрабатывать/тестировать функционал где-то в сторонке, а уже потом внедрять его в рабочие системы. Чаще всего проекты  разбиваются на маленькие и средние задания на разработку. Такое задание попадает к разработчику, он в своей копии пишет то, что надо.  Потом, на его же копии всё тестируется, и если все хорошо, через хранилище обновляется рабочая БД. Не будем останавливаться на том, что так разработку вести не очень хорошо, но что, то есть, и уверен у многих похожие ситуации.

Теперь подробнее о таких особенностях:

 

Правила работы с корнем конфигурации

Правило номер 1: не держите захваченным корень конфигурации!

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

  • Захватываем корень;

  • Добавляем новый объект;

  • Помещаем корень и новый объект;

  • Захватываем объект обратно.

Думаю, многие работают по такому принципу. Вроде удобно, что корень всегда свободен для других разработчиков. Если даже новые объекты обновляются на рабочую - тоже ничего страшного (на них нет прав и их никто не увидит). Однако такой способ, помимо удобства, может содержать не очевидные неожиданности. О которых далее.

 

 

Составные поля - зло

Составные поля содержат в себе несколько неожиданностей при работе с хранилищем при нашей схеме разработки. Приведу несколько примеров.

  • Добавление нового документа. Допустим необходимо добавить новый документ, но он, в свою очередь, является регистратором уже существующего регистра. Если мы пойдем по стандартному пути работы с корнем, вот что нас ждет. Мы добавим документ и поместим его в хранилище, т.е. этот документ появится в рабочей базе. В итоге у поля регистратор существующего регистра добавится новый тип документа, на который, я напоминаю, у пользователей нет прав. Таким образом, в рабочей базе пользователи могут словить “Нарушение прав доступа” при чтении таблицы регистра.

  • Приведу другой похожий пример связанный с нумераторами. Добавляем новый документ и устанавливаем ему существующий нумератор, который уже используется в других документах. Затем также бездумно помещаем этот документ в хранилище. Всё, при записи любого документа, которому установлен данный нумератор ловим нарушение прав доступа на все тоже чтение нового документа.

Правило номер 2: думайте о составных полях и правах. Не помещайте объекты в хранилище бездумно!

 

Правила работы с ролями

С ролями всегда нужно работать аккуратно. Ни в коем случае нельзя надолго захватывать существующую роль. Захватил роль-->добавил права-->поместил обратно. К сожалению, так случается, что работа над какой-либо задачей затягивается и у разработчика в его копии остается много захваченных объектов. Это в принципе не критично, но не в случае с ролями. С большой вероятностью, случится ситуация, при которой другому разработчику понадобится срочно роль.

Вообще, при разработке новых подсистем, я придерживаюсь такого принципа. Я просто добавляю новую роль(или несколько) для данной подсистемы и на все новые объекты даю права исключительно этой роли. Когда подсистема внедряется, то просто нужным пользователям добавляем эту роль.

 


 

Особо хочу отметить очень не очевидную проблему при работе с ролями вроде ПолныеПрава или Администратор. В общем с любыми ролями, у которых установлен флаг “Устанавливать права для новых объектов”:

 

 

Сначала сформулирую правило номер 3: старайтесь никогда не захватывать в хранилище роль ПолныеПрава!

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

Так почему же не надо захватывать такие роли?

Ну, во-первых, в большинстве случаев это просто не нужно.

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

 

Дополнительные полезные советы:

  • Старайтесь помещать объекты в хранилище не по одному, а “пакетом”: все объекты, измененные в рамках одной задачи.

Во-первых, это уменьшает вероятность ошибок “целостности”. Я о них подробно и не говорил, потому как это должно быть более менее очевидно. Если мы изменили обработку проведения документа, из которой вызывали процедуру общего модуля, то нужно поместить и документ, и общий модуль.

Во-вторых, позволяет проще ориентироваться в версиях конфигурации. Тут я советую также пользоваться метками для версии в хранилище.

  • Пользуйтесь окном “Хранилище конфигурации”. К сожалению, почему-то не все знают о его существовании. А тем не менее, оно очень полезное. Например, в нем можно пакетно захватывать, помещать объекты в хранилище (через ctrl), ставить отборы (Все захваченные и Все захваченные пользователем).

До этого окошка не очень удобно добираться из меню, но в этой статье можно посмотреть, как его удобно расположить в конфигураторе. Единственно, чего очень не хватает этому окну, так это отбора по подсистемам.

 

 

  • При какой-либо не удачной попытке подключения к хранилищу (например, Вы случайно нажали отмена при подключении), 1С выдаст Вам вот такой диалог:

 

 

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

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

 

Спасибо за внимание, надеюсь для кого-то информация окажется полезной. У кого есть что добавить, добро пожаловать в комментарии.

См. также

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    10448    84    4    

116

Групповая разработка (Git, хранилище) Программист Руководитель проекта Стажер Бесплатно (free)

Про изменения и новинки в агрегаторе открытых проектов OpenYellow, которые появились с момента его создания: про портал, Github и Telegram

15.07.2024    2374    bayselonarrend    8    

22

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

О проблемах новых 1С-проектов в общем океане открытого программного обеспечения.

07.07.2024    2765    bayselonarrend    57    

34

Групповая разработка (Git, хранилище) OneScript Программист Платформа 1С v8.3 Бесплатно (free)

Скрипт для работы с SonarQube и локальным репозиторием Git.<br> Цель проекта – возможность выполнить быструю проверку качества кода перед тем, как помещать доработки в рабочее хранилище. В Sonar и Git выгружается не вся конфигурация, а только объекты из заданного списка.<br> https://github.com/vkrivov/go/

02.07.2024    2435    vkrivov@yandex.ru    8    

18

Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Столкнулся с проблемой при загрузке метаданных в СППР из GitLab на сервере 1С под Linux (РЭД ОС 7.3). При загрузке метаданных конфигурации, процесс загрузки длился несколько секунд и "благополучно" (без сообщений об ошибке) завершался. При этом метаданные не загружались.

1 стартмани

02.07.2024    473    0    Live    2    

3

Групповая разработка (Git, хранилище) Программист Стажер Бесплатно (free)

Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.

08.04.2024    1223    bayselonarrend    2    

33

Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Доработки 1С:ERP на крупных проектах можно организовать, не внося изменения в саму типовую конфигурацию, а используя только расширения и отдельные «микроконфигурации». Расскажем о том, как это сделать без EDT, используя процесс разработки GitHub Flow.

02.04.2024    6848    Begemoth80    24    

51

Групповая разработка (Git, хранилище) OneScript Системный администратор Программист Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    2053    bayselonarrend    3    

41
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. kapustinag 03.06.13 12:09 Сейчас в теме
C картинками какая-то проблема. Не отображаются картинки в тексте публикации, только место пустое. В трех доступных мне броузерах посмотрел - везде пусто. Или все-же у меня локальная проблема?
2. _also 489 03.06.13 12:41 Сейчас в теме
(1) kapustinag, проверьте сейчас, пожалуйста.
3. mentos 26 03.06.13 13:56 Сейчас в теме
Пользователей хранилища мы называем по имени базы на 1с сервере.

вот за это спасибо :) простейшая вещь, но в голову никогда не приходила
4. _also 489 03.06.13 14:21 Сейчас в теме
(3) mentos, да, это очень удобно
5. kapustinag 03.06.13 15:43 Сейчас в теме
Похоже, стоит фильтр на нашем прокси-сервере. Картинки-то не на сервере Инфостарта, а на google...
С другого компьютера, внешнего, зашел - все Ок.
6. _also 489 03.06.13 15:47 Сейчас в теме
(5) kapustinag, видимо инфостарт не копирует лишнего на свой сервер. Я в статье делал вставить картинку и указывал url.
7. speshuric 1332 03.06.13 21:20 Сейчас в теме
"Рабочая база подключена к хранилищу;" - после этого читать желание пропало.
8. _also 489 03.06.13 21:24 Сейчас в теме
(7) Поясните свою точку зрения
9. speshuric 1332 03.06.13 22:35 Сейчас в теме
(8) _also
Сразу скажу, что я и сам какое-то время так делал. Пока не переубедил коллег. Я считаю, что вешать продуктовую базу на хранилище - по надёжности это примерно аналог того, что подписаться на автообновления midnight сборок. Правильным вариантом является выплёвывать файлы поставки и держать продуктовую базу у себя на поставке "на замочке". В этом режиме можно обновлять и ежедневно и еженедельно и вообще, как пожелаете.
Лет 5 с лишним назад накидал схемку того, как примерно это выглядит. Нюансов там заметно больше, но для начала обсуждения вполне пойдёт.

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

Если исправления не авральные, то как бонус - можно протестировать именно тот файл поставки, который пойдёт в бой, хотя б "джентельменский набор": синтаксис, проверки конфы, логин админа, логин пользователя, время реструктуризации. Автоматизируется на раз-два, зато не сможете совершить ошибку, которую допустила 1С в релизе УПП 1.2.8:
Исправлена ошибка 00092921:
При входе пользователя не с полными правами происходит ошибка.

Опять же заранее будет видно если косяк с реструктуризацией и т.п.

Я ни в коем случае не спорю с самими советами. И роли, и составные типы, и многие другие советы вполне разумны и интересны, но модель "рабочая на хранилище" меня пугает очень сильно.
Boulala; Дмитрий74Чел; h00k; KapasMordorov; pit201201; omut; kuntashov; bird21; CratosX; Ish_2; laduk; xzorkiix; _also; awk; +14 Ответить
10. _also 489 03.06.13 23:28 Сейчас в теме
(9) speshuric,
держать продуктовую базу у себя на поставке "на замочке"

это мечта. Конкретно в наших реалиях авральных исправлений порой больше, чем нормальных обновлений, так что... НУ не можем мы себе такого позволить.
Спасибо за схемку, подход у Вас очень правильный. Однако я считаю ее слишком тяжелой для случаев небольших баз, с небольшим количеством пользователей, И... с низкоквалифицированными программистами.
В любом случае спасибо за конструктив, этого я и ждал :)
16. speshuric 1332 03.06.13 23:55 Сейчас в теме
(10) Как раз с низкоквалифицированными сотрудниками схема "с поставкой" лучше. Натаскать сервис-деск или кого-то подобной квалификации на проверку и формаирование релиза достаточно просто, а времени высвобождается немало: это и проверка и выгоняние пользователей и само применение. Когда писалась эта схема как раз одна из целей была пульнуть в сопровождателей релизом и самому не греть голову.
(11) pumbaE, Веток не хватает. Git не хватает с распределённой структурой. Есть такое. Но цикл сборка/поставка дисциплинирует вне зависимости от того есть тестировщик или нет. Просто же: собрал, проверил синтаксис и конфу на ошибки, проверил реструктуризацию, проверил логин великого админа и проверил логин твари ничтожной. Да хоть бы и в УПП - это займёт на нормальной железяке около получаса от силы. Не хочешь сам - отдай "подовану", заодно пусть посмотрит изменения и покритикует, если время есть. Выше приведён пример, что и фирма 1С когда-то забивала на эти проверки и к чему это приводило. Не нужен на этом уровне ни билдбот, ни отдельный тестер. Нужен просто этап "Я собрал поставку, я сейчас её накачу и хочу проверить, что мне не придётся сидеть 2 выходных и восстанавливать работу предприятия".

Давайте не будем пенять на 1С и ждать когда она "повернетса к программистам" (кстати, какой стороной? :) ). Хочется, чтобы был идеальный код - начни с себя и своего коллектива. Юнит-тестов не хватает? Так надо писать и показывать на практике результативность этого подхода, другие методы не сработают.
KEV8383; xzorkiix; _also; +3 Ответить
17. _also 489 04.06.13 00:00 Сейчас в теме
(16) speshuric, низкоквалифицированные сотрудники порождают такой код, что придется каждый день с поставки снимать.
За "начни с себя" - огромный плюс. Мы все кивать горазды, а сами производим тот еще.. продукт ((
11. pumbaE 03.06.13 23:32 Сейчас в теме
(9) speshuric, не хватает хранилищу "веток".
Ваша схема подойдет когда все таки проводятса какие-либо автоматические тесты или даже есть отдельный тестировщик или же пользователи проверяют в отдельной тестовой базе данные, перед помещением в рабочую базу.
Но чаще, к сожалению, конечный потребитель доработок является и тестировщиком и пользователем одновременно и об ошибках програмисты узнают утром не от build-бота, а от полоьзователей.

p.s: Имхо, вряд ли что-то изменится кардинально даже с выходом 8.3 и возможности тестирования, если сама 1С не повернетса к программистам и не будет пропогандировать "best practice" среди программистов и будет публиковать тесты к типовым конфигурациям (скептик во мне заявляет "Не бывать этому!"). Возможно будут единицы использовать тесты, чего таить и сам не без греха, но я то постараюсь вместе с Артуром Аюхановым поразрабатывать в стиле TDD , а основаня масса програмистов так и будет писать комментарии в коде "Здесь было Вася" и считать, что это верх совершенства в способах доработок типового кода, а про тестирование даже понятия не иметь.
p.s.s: Я знаю, что автоматическое тестирование - это не волшебная пилюля.
kuntashov; KEV8383; _also; +3 Ответить
12. _also 489 03.06.13 23:40 Сейчас в теме
(11) pumbaE, подписываюсь под каждым словом. Но думаю, что тестов к типовым мы так и не дождемся. И, кстати, даже "Здесь был Вася", к сожалению, не все пишут.
13. _also 489 03.06.13 23:42 Сейчас в теме
(11) pumbaE, Жень, а не тестировал работу с хранилищем в 8.3. 1С там заявляла какие-то ништяки. Мол работать будет сравнение быстрее?
14. pumbaE 03.06.13 23:49 Сейчас в теме
(13) пока нет, дети заболели, нет времени. По тому что видел, для себя кардинального ничего не вынес. Пока вижу структуру хранилища похожую на git(но могу и ошибаться, но тут трудно что-либо новое придумать как со справочником "Номенклатура"). Скорость по сравнению с хранилищем старым действительно быстрее. По сравнению с аналогичной историей экспортированной в git хранилище еще не тестировал.
15. _also 489 03.06.13 23:52 Сейчас в теме
(14) pumbaE, я понял. Надо что-то придумывать с ролями и частичной выгрузкой в xml 8.3 и переходить на git...
27. omut 07.08.14 22:56 Сейчас в теме
(9) speshuric, полностью поддерживаю. Сам работаю точно по такой же схеме :)
Отдельно по запуску (пароли, пароли, пароли...) У кого нет снегопата: напишите батник с параметрами запуска и сразу попадете в конфигуратор под нужным пользователем в нужную базу и подключением к хранилищу. Если баз много, то файлов будет тоже много. Но это уже, что называется, на любителя. На всякий случай, если кто не знает, пример строки в батнике такой:
"C:\Program Files (x86)\1cv82\ВАША_ВЕРСИЯ_ПЛАТФОРМЫ\bin\1cv8.exe" DESIGNER /S СЕРВЕР_1С/ИМЯ_БД_1С /NИМЯ_ПОЛЬЗОВАТЕЛЯ_1С /PПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_1С /ConfigurationRepositoryNИМЯ_ПОЛЬЗОВАТЕЛЯ_ХРАЛИНИЩА /ConfigurationRepositoryPПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ_ХРАНИЛИЩА (для клиент-серверной БД, если файловая база, то вместо /S ставим /F и дальше папку БД вместо сервера и имени БД)
29. Stas-ch 35 18.04.16 11:07 Сейчас в теме
(27) omut,
а зачем батники? Можно ведь все прописать сразу в параметрах запуска 1С. Из минусов - надо прописывать у всех, кто работает с базой (копи-паст рулит), зато нет кучи батников.
18. Kutuzov 744 04.06.13 08:12 Сейчас в теме
Еще хотелось бы подробную инструкцию по настройке подключения к хранилищу через интернет.
19. SPID 04.06.13 09:04 Сейчас в теме
По поводу "Захватил корень - добавил объект - поместил корень - захватил объект и дальше его разрабатываеш" тоже кроется подвох, если этот объект регистр - нужно не забыть добавить хоть одно измерение и назначить регистратор, если он необходим. Если поместить пустой регистр в хранилище, то для разработчика получившего конфигурацию с хранилища ждет сюрприз - он не сможет обновить конфигурацию БД, конфигуратор будет "ругаться" на этот регистр без регистратора и/или без измерений.
zqzq; romankoav; zuxelzz; vasiliy_b; +4 Ответить
20. _also 489 04.06.13 09:11 Сейчас в теме
(19) SPID, согласен. Вообще лучше все новые объекты, в том числе с реквизитами за один раз добавлять.
21. xzorkiix 35 05.06.13 11:07 Сейчас в теме
текст читаешь, приговаривая "конечно", "это же логично". Но всё равно полезно.

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

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

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

Имхо, на инфостарт-евенте скорее такого простого доклада ожидал, а поверх какие плюшки появляются при внедрении иных продуктов, технологий, методологий.
22. pumbaE 05.06.13 11:37 Сейчас в теме
(21) xzorkiix, не ставил себе целью описания работы с хранилищем. Рассказывать банальные вещи не очень хочется ни мне и вам их слушать тоже думаю не сильно охота.

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


p.s.: Ben Collins-Sussman: Итак есть два "класса" программистов-разработчиков, назовем их "20%" и "80%", основная движущая сила индуструии программного обеспечения - это "80%"-ные парни... Их знаний в точности достаточно, что бы сделать свою работу, затем пойти домой и забыть о комьютерах...
Жутка правда №1 - Основной объем...ПО - создается вышеупомянутыми "80%" программистов.
Жуткая правда №2 - Большинство "альфа - гиков" забывают "жуткую правду №1" .

Вышеупомянутым программистам вообще трудно использовать контроль версий, а вы собираетесь объяснять им разницу между "pull" и "update"...

Ben Collins-Sussman - автор svn.
_also; vikad; +2 Ответить
23. laduk 15 05.06.13 13:01 Сейчас в теме
Статья ни о чем, да еще и с неадекватными советами типа: "имя пользователя по имени базы и одинаковые пароли" - по моему полнейший бред;
"Рабочая база автоматически обновляется из хранилища" - да за такое руки поотрывать мало
24. _also 489 05.06.13 13:36 Сейчас в теме
(23) laduk, я рад, что Вам понравилось )
25. zqzq 25 05.06.13 16:56 Сейчас в теме
имя пользователя по имени базы и одинаковые пароли

ИМХО лучше на каждого программиста своего пользователя (с правами захвата) + админа хранилища + юзера с правами только на чтение для обновления рабочей из хранилища (лучше заходить с одного сервера). Тогда и нормальный отчет по истории работы с хранилищем будет. Естественно, для сложных случаев лучше рабочую обновлять поставками/объединением.
26. cdover 07.08.14 18:20 Сейчас в теме
всё по полочкам. Спасибо!
28. Templ 15.04.15 11:35 Сейчас в теме
Из-за чего может быть. Внесли изменения из хранлища в основную базу. И оказалось что в рабочую базу затянулось старая версия изменений.
30. Stas-ch 35 18.04.16 11:10 Сейчас в теме
а вот никто не знает как в случае копирования базы с изменениями, не внесенными в хранилище, перенести информацию о подключении к хранилище в эту новую базу?
т.е. средствами SQL скопировали базу, старую убили (или пока еще нет, но скоро убьют). Захожу в новую базу а информации о подключении ее к хранилищу нет - при попытке подключения к хранилищу вся информация замещается данными хранилища. Приходится выгружать через конфигуратор все изменения и закачивать их в новую базу. Муторно. Может есть способ проще? Поделитесь.
31. Дмитрий74Чел 237 08.10.18 09:14 Сейчас в теме
(30)Официально способа нет. Вы неправильно понимаете суть регитстрации базы в хранилище.
Информация о подключении харнится на 2х сторонах: и в базе (к какому хранилищу подключена, скорее всего, просто путь к хранилищу), и в хранилище (какие базы подключены, скорее всего просто в виде "сервер-база").
Таким образом, при копировании базы, в ней остается информация о хранилище, поэтому и выходит окно с предложением ввести логин и пароль. Но логин и пароль (правильные) не примет само хранилище, т.к. путь к базе не совпадает с сохраненным в хранилище.

Цитата с ИТС:
https://its.1c.ru/db/v8doc#content:82:1:issogl2_28.1.2.подключениекхранилищу
Если имя пользователя зарегистрировано и для этого пользователя информационная база еще не была подключена к хранилищу конфигураций, то производится подключение и устанавливается связь: в хранилище по данному пользователю записывается информация о конфигурации и ее месте расположения.

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

Если для данного пользователя в данный момент времени есть открытая конфигурация, связанная с указанным пользователем, то конфигуратор выводит предупреждение об аутентификации.

Если для данного пользователя в данный момент времени нет открытой информационной базы, но данные о месте расположения не совпадают с данными о связи (конфигурация расположена в другом каталоге, или подключение производится с другого рабочего места), то конфигуратор выводит сообщение: Для данного пользователя уже имеется конфигурация, связанная с данным хранилищем конфигурации. Продолжить? Если нажать кнопку Да, то происходит установка нового подключения, текущая конфигурация заменяется конфигурацией из хранилища и устанавливается новая связь текущей конфигурации с хранилищем для данного пользователя.
32. romankoav 4 31.05.19 12:37 Сейчас в теме
Все внимательно прочел, но так и не увидел веских доводов (кроме странных страхов) почему не стоит не подключать рабочую базу к хранилищу. Так почему же?
33. CratosX 113 04.12.19 11:59 Сейчас в теме
(32) Аналогично. Используем на мелких доработках, плюсов от этого больше, чем минусов (для оперативных исправлений нужно захватывать объект, а он может быть захвачен кем-то). На крупных же конфигураций и/или с большой командой разработчиков хорошо описано в (9)

Кстати, раньше я как-то указывал метки к версиям хранилища, а сейчас не нашёл, как это сделать, подскажет кто?
Оставьте свое сообщение