В общем, есть такая проблема.
Многие - и программисты(у нас их много) и иногда юзеры любят залезть в рабочую базу в конфигуратор. При этом, не зная пароль от Хранилища периодически на вопрос "Отключиться от хранилища конфигурации?" вместо того, чтобы нажать "нет" жмут "Да!", чем постоянно вызывают у меня лютый баттхерт и гору строительных материалов.
Как с этим бороться? В логах видно только того, кто заходил в конфигуратор, но никто не признается, кто отключал.

(26) это читерство

(0) зайди в пафигуратр и не выходи оттуда никогда - никто и не отключит тебя от хранилища )

Рабочая база подключена к хранилищу?!
Вазелин, стенка там.

(29) а что есть варианты?

(30) сравнить, объединить с конфигурацией хранилища — только так!

(31) можно еще - два хранилища. В одном разработка, а к другому база подцеплена

(32) а смысл?

И вообще, когда уже 1С сделает бранчи в хранилище?

А просто получить изменения из хранилища и нажать f7 почему нельзя?

(33) так есть персонифицированная история изменений рабочей базы и можно быстро откатиться на любой релиз (с нюансами правда)

(34) +100500

(35) если бы были бранчи, то вполне.
А так — большая вероятность, что в рабочую базу влетят недопереписанные неоттестированные куски

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

(38) как в базу влетят недопереписанные куски если их в хранилище еще не положили?
а что такое бранчи?

(39) по моему ты что-то путаешь..

(40) wiki:Система_управления_версиями#.D0.92.D0.B5.D1.82.D0.B2.D0.BB.D0.B5.D0.BD.D0.B8.D1.8F

(41) ты просто не работал в команде

(40) как это не положили? Еще как положили!
Бранчи — это ветки. Допустим, тебе надо внести какие-то изменения, которые затрагивают несколько объектов. Ты создаешь бранч — виртуальную копию конфы и вносишь изменения в ней. Другие разработчики этих изменений не видят, пока ты не объединишь бранч с общей ветвью.

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

(45)+ долбанный автокорректор! Сконфуженно=конфу

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

Или вы предлагаете с одними и теми же объектами одновременно работать?

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

+(44) особо внимательные пионэры могут сказать: "ХА! Так а какая религия мешает скопировать хранилище?"
скопировать-то ни чего не мешает, только вот работать с этим будет трудно по дум причинам:
1. механизма слияния веток нет
2. авторизация не наследуется, что порождает лютейший баттхёрт при администрировании толпы хранилищей
3. испробовано много раз - соотношения профита и гемора не позволяет называть это "механизмом ветвления хранилища конфигурации 1С"

(47) а если они еще кому-то нужны? а если ты объекты на месяц захватил для каких-нить глобальных переколбасов, а тут срочно потребовалось какой-нить баг в рабочей базе исправить?
Самая феерия наступает, когда у тебя команда из нескольких человек и задачи пересекаются по объектам:
1. Петя хочет захватить объект А, захваченный Васей.
2. Вася не может отпустить объект А потому что он внес изменения и ждет, пока изменения протестируют
3. Петя не может работать без объекта А
4. Вася должен объединить результат своей протестированной работы с результатом протестированной работы Пети
5. Петя не может поместить свои изменения потому, что не может захватить объект А

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

+(50) теоретики могут идти лесом с песнями - пример абсолютно живой и рабочий, имевший место три месяца назад

(50) а с бранчами вам типа в вашем бардаке легче было бы?
Петя с Васей захватили один и тот же объект и работают с ним, изменяют одну и ту же процедуру.
Наступило время объединаться. И чо? Кто главнее?

+(50) забыл пункт 6 - тестеры ни куя не делают по объекту А, поскольку не могут взять в толк, зачем им тестировать не законченную работу (и их легко понять)

(52) ты ни фига не понял. С бранчами Петя с васей работают в одной ветке и захватывают так же по очереди:
1. Петя с Васей не ждут тестеров и коммитят, как только они закончили работу
2. Тестеры не делают бестолковой работы
3. В конфигурацию рабочей базе ни как не могут попасть даже временно недоделки

Вот теперь я понимаю кто РАУЗ написал.

(52) и это не бардак, это норма, когда команда достаточно большая

(55) повзрослей уже

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

(44) и как грамотно разрулить такую ситуацию? мне приходится выгружать в cf  и отменять захват, потом сравнивать/объединять с cf

(58) а ты смелый...
на самом деле надо отделять хранилище конфигурации рабочей базы от хранилища разработки

Ну хорошо. Вася поместил в хранилище "то что есть". И теперь с ним работает Петя.
В чем проблема? Пока вы из рабочей базы не получите изменения они так и будут в хранилище лежать.

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

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

(61) потому что в рабочей базы изменения УЖЕ нужны (ведь пишут не только Вася и Петя)

(62) и как решить проблему Пети-Васи в рамках одного незалежного хранилища?

(64) в рамках одного - посредством создания второго, я ж сказал раз 5 уже...

еще: как решить проблему, описанную тобой в (50) в рамках того "n-ого" незалежного хранилища?

(63) lkz k.,j

твою мать!
для любой, говорю, команды актуально. даже для одного человека.

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

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

(69) странно. А что будет если ваши две команды пишут механизм, захватывающий общие объекты? Одни захватили - у себя - пишут свое, другие - захватили в своем хранилище свое и пишут другое. Потом - воссоединись, код...Алилуя (3 раза?)

(71) были бы ветки, можно было бы получать изменения из мастера (рабочего хранилища) в ветку. А так - регулярное сравнение/объединение со срезом рабочего хранилища + переговоры с коллегами.
А фигли вы хотели - бранчей в 1С нет...

(71) в восьмерке объединение сделали на загляденье. конфликты любо дело разруливать

(71) Ну дык потом программисты проверяют "всё ли правильно и все ли их изменения попали адекватно в рабочее хранилище."
какая-то каша и двойная работа..

разделение хранилища разработки и хранилища обновления всех проблем не решает, но хоть какие-то

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

(76) а сколько у вас человек работает с конфигурацией?

(71) Мне кажется самое время доставать письки и мерятся: 3800 юзверей, 1 база подключенная к одному хранилищу, быдло-кодерастов - 15 человек - у каждого своя локальная копия подключенная к единому хранилищу. Т.к. отделы разделены и их задачи практически не перескаются - проблемы Пети-Васи решаются у нас так: Сергей Иваныч, тебе то-се не нужно в ближайшее время. Сергей Иваныч - неа. Все - оно мое. Если кому надо - ну а кули ж вы молчали раньше? Если нужно - ВДРУГ - сохрани cf, откатись - потом быстро поднимешься и сольешься с хранилищем.

Операцию по созданию второго хранилища никому пока в голову не пришла :)

(77) смотря с какой... С самой толстой 600+ одновременных

(78) >отделы разделены и их задачи практически не перескаются
как вы этого добились?

(79) 600 человек работают с одной конфигурацией? вы в 1с работаете?

(80) по подсистемам этого можно добиться..

забыл - есть смотрящий за хранилищем. Рабочую базу из хранилища обновляет он по сигнальному костру и образов от белого дыма :) Конечно, ситуация когда что-то не доделано и вливается - это из разряда 3,14здец, нежели норма. Откат - больше внештатная ситуация, но не 3,14 =) Повторюсь, проблем Васи-Пети нету у нас.

вот, рекомендую статью про то, как работают с нормальными системами контроля версий http://nvie.com/posts/a-successful-git-branching-model/

(83) у вас там 15 сферических программистов в вакууме, которые функционал всей конфигурации держат в уме и ни когда не ошибаются?

Вот так как у Новикова я и имел ввиду. Вот это нормальная организация труда.
У нас конечно не 3800 пользователей, а около 250, но в остальном один в один. И никогда проблем Пети-Васи не было.

всё впереди у вас

(87) ЛефМихалыч, не сочти за оскорбление, но я бы так сказал: у нас уже все в прошлом :)

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

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

(90) рад за вас безмерно. Чо ты от меня хочешь по этому поводу?

Фез не зря хранилище 1С называл "гноилищем", а это человек, собаку съевший на групповой разработке. А 1Сники, как всегда в своем репертуаре - слаще морковки ничего не едали, и с пеной у рта доказывают, что слаще и не надо.
"Гит, Меркуриал, Фоссил? Не, не слышали".

(91) Печально, но факт - ВАЩЕ НИЧЕГО :)

(92) вброс засчитан

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

"Сделать в недоступном месте центральную базу, а рабочая пусть будет распределенной.
И делайте с этой ЦБ что захотите."!

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

1. Позиция 1с по поводу хранилище озвучивалась и не раз.
2. не надо подключать к хранилищу рабочую базу. Для чего придумали поставки, например?

(92)(94) Это не вброс, это правда жизни. Если поработал с git, hg, bzr , а потом начинаешь работать с хранилищем от авторства 1С и понимаешь что делали его из принципа пипл и так схавает.

"продакшен" базу подключать к хранилищу - мдя...

в нормальных системах девелоперы туда вообще доступа не имеют

(98) Имхо, 1с разработало хранилище для себя. Их, похоже, устраивает. А остальные перетопчутся... :)

ничего мерзее хранилища 1с встречать не приходилось

(101) пусть само бы с ней на УПП и сношалось например

(103) Насколько я понял - они УПП как раз при помощи хранилища как раз пишут.

(104) молодцы... у меня терпения не хватает... checkout - и пусть весь мир подождет...

(0) По пальцам бить не вариант?

(0)
доступ к рабочей базе должен быть только у админа БД и начальника отдела...
у всех остальных отобрать

Фига вы тут нафлудили)))
"Сравнение и объединение" - из клюшек еще что ли не выросли?
Для 8-ки хранилище самое православное средство групповой разработки. Каждый прогер работает в своей базе, а в главную, по-идее, принимать изменения должен старший ответственный программист или что-то в этом роде.
Других средств групповой разработки 1С-ом не придумано. Да и не надо.

(107)
Так, короче и сделал. Забрал у всех админские права в рабочей базе, кроме начальника и себя))))) Жду реакции и копаю яму под строительный материал)))

(108) как это не надо? С другими программами контроля версий работали? Прав (91)
"с пеной у рта доказывают, что слаще и не надо. "

(97) "не надо подключать к хранилищу рабочую базу."
я тоже это видел на прошлой работе. там мне это преподали как аксиому. а почему они так решили - я не понял.
можно в двух словах нарисовать?

(97) не сочтите за занудство, а какая позиция у 1с по вопросу хранилища?

(112) где-то как-то так: "проблемы голожеппых андеев блаароднага шерифа традиционно ниипут"

может решится всё тем, что научатся базу разбирать-собирать на сотню маленьких xml? тогда её хоть под гит, хоть под меркуриал, хоть под свн клади

(114)+ не базу, а конфигурацию, конечно

Мечты, мечты,
Где ваша сладость?

Холивар какой-то развели...
1) "Продакшен" на поддержки, доступ у одного человека (пароли в конверте и в сейфе).
2) Рабочая конфа у прогов своя подключена к хранилищу.
3) У тестеров копия рабочей с доработками. Так как сначала обновление накатили тестерам.
4) Если все ОК, то релиз и накат в рабочую, если нет то в цикл на доработку.

Другие системы, к сожалению для других ЯП. А так сбор-разбор-тудым-сюдым... 1С это же не ЦеПП.

(117) +100
Тоже так работали.
Разработчиков было человек 15. И никто никому не мешал. Разработчики колбасят код, помещают в хранилище. Делается релиз. Тестеры тестят релиз. Если нет критических ошибок, выпускается релиз пользователям, если нет то исправление ошибок и опять тестирование и т.д.

(112) 1. Если хватате нам - фиг ли вы выеживаетесь.
2. Осовное направление развития 1с - это пользовательский функционал. Хранилище относится к разработке, поэтому стоит на последних местах

(114) Белов вроде что-то такое делает

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

(121) Сразу 2 вопроса:
1. каким образом заливаете изменения в рабочую? Все? Или отбираете..
2. как тестируете изменения перед залитием.

(122) Сильно в подробности вдаваться не буду, отмечу, что по методике обновления не чаще раза в неделю (и то это редкость). Тестирование в 3 уровня после программиста, последний уровень - бухгалтер (да, на нем тоже ответственность). Заливаем полностью все. Изменения подготовили и за раз обновили все рабочие.
Еще замечу. что перед обновлениями продумываем стратегию отступления

+(123) стратегия простая: как можно дальше от самодурства. Реально скорость разработки/доработки выше, чем у электровеников

(124) это с учетом разработки стратегии отступления?)

(125) Да. Требования тут по изменению УПП очень серьезные