Кто как учитывает версию хранилища внедренную в рабочую базу?

Чо?

(0)Оно само учитывает если что.

Как узнать какая из версий сейчас загружена в рабочую базу?

Сравнить с хранилищем - не вариант?

+(0) открой для себя Конфигурация ->хранилище конфигурации->История хранилища

(4) Нет

(5) Умно

(3)А зачем?

(0) поставить соответствующий номер в "Свойство" базы

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

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

(10) Все решает эллементарно. Разработчики помещают изменения в хранилище по мере их готовности и оттестированности. Тот кто делает релиз изменяет номер конфигурации.

(12) номер = версия.
и у тебя всегда будет все отлично.

(9) Как вариант, но мне не очень нравится. Человек может забыть
(11) Вести запись где? В этом-то и вопрос
(12) А менять номер конфигурации где? В рабочей базе?

(14) ПКМ на корне->Свойства->Имя

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

(16) а при обновлении версия рабочей базы получит номер загруженной (обновленной) конфы.

(15) На корне в хранилище или уже в рабочей?

(16) Для смены в хранилище нужно каждый раз захватывать корень. Что не всегда возможно

(18) запомни меняется ВСЕГДА ТОЛЬКО конфа в хранилище. Рабочая БД вообще меняется исключительно только через обновления

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

(20)Ну почему?  Если уже релиз принял в рабочуюю там и помять можно сразу

(19)Почему не всегда?  Помоему корень - это один из само редко захватываемых объектов чтобы конфликтовать

(20) Не вариант. А если корень у кого-то уже захвачен?
(21) А зачем захватывать корень?

(22) рабочая должна быть на поддержке. Иначе будет хаос. Внесли изменение в хранилище, обновили БД рабочей базы, внесли изменение в рабочую базу, а в хранилище нет и в сл. раз при обновлении из хранилища изменения затрутся

(24)
в двух случаях.

1. ты меняешь свойства конфы(имя или синоним)
2. ты добавляешь новый объект в конфу.

(24) корень захватывать нужно оч. редко. И что значит не вариант? Так надо работать.

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

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

(24) Отпустит. Реально корень нужен, чтобы поместить/удалить новый объект метаданных. Соответсвенно если разработчик хочет сделать новый отчет или обработку - нечего корень захватывать.
А если нужн справочник, то ничего страшного, если перед сборкой релиза для залития в рабочую базу либоб помещаются изменения с корнем, либо сохраняется конфигурация и корень отпускается без внесения изменений. Проблем в этом, имхо, нет.
Только некоторое неудобство

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

(28) Нужно только учитывать тонкости, например регистры накоплений без регистраторов, или документы-регистраторы регистра накоплдений, на которые не прописаны права...

(31)Конфликта все равно не может быть пока ты держишь объект.А так -кто к чему привык:-)

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

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

(34)Если ты не накатываешь специально конфу из истории, то она всегда будет у тебя последняя. Мне например ни разу не приходилось накатывать историю.Так зачем огород городить?

(35) Мне важно

(34) "Корень могут держать долго, если добавляют много объектов"

Объектов которые требуют захвата корня - не может быть много и какой смысл делать это "в час по чайной ложке"? Что мешает действовать "вставил - отпустил"???

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

(36) А мне приходилось. Может в последний момент выясниться что последняя помещенная версия содержит ошибки и внедрять её ни в коем случае нельзя и ждать версии с исправлением тоже времени нет. Поэтому внедряется предпоследняя версия

(40) "может лучше в консерваторию что поправить" (с)

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

(41) Т.е. ты всегда пишешь без ошибок?

(42)
>> Может в последний момент выясниться что последняя помещенная версия содержит ошибки и внедрять её ни в коем случае нельзя и ждать версии с исправлением тоже времени нет. Поэтому внедряется предпоследняя версия

т.е. предполагается что есть некая предпоследняя, еще не внедренная версия (!), она не содержит ошибок (и как это выяснили если она даже не внедрялась?) и надо срочно ее внедрять, так получается?

(42) хм-м-м... а ты всегда тестируешь свои программы исключительно на пользователях???

Лично я в хранилище помещаю только то, что уже оттестировал с разных сторон. Я - не прав?

(43) Да

(43) ну да.. при этом выясняется, что последняя версия содержит исправления критических багов предпоследней - поэтому и накатывают именно предпоследнюю, так как о критических багах того релиза уже "кое-что известно" :-)))

(45) вам надо что-то менять в порядке работы. 1С не расчитан чтобы так работать.

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

(45)Чую версионность тебя не спасет.Потому что бардак систематизировать нельзя:-)
Организуй правильно регламент работы с хранилищем- и все желания из (0) отпадут сами собой

(47) на "такое" не рассчитана ни одна нормальная среда разработки

(48)Лишать 5% зп каждого кто кинул в хранилище серьезный баг.Быстро начнут тестировать перед сбрасиванием

(48) может они еще и в одном хранилище совершенно не связанные конфигурации пишут?

(51) Это не законно

(48) и что??? Наличие колхоза, который заливает в одну помойку - это не показатель что "иначе жить нельзя"... Для любой серьёзной системы должен быть  например архитектор, которому и сдаются различные доработки и только архитектор накатывает "то в чём он уверен" на продуктивную базу

Архитектор - не тестировщик. И он не может отвечать за то что написал кодер

(51) ошибки могут быть из-за не состыковками с чужими доработками - а такие ошибки "локальным тестированием" поймать нельзя

(53)Почему это?  Причинение ущерба компании на лицо.А это в любом стандартном договоре прописано

(56)Значит должен быть чел который все вместе склеивает и тестирует перед релизом

(55) Ты его хоть груздем назови - но должен быть ответственный, который ПРИНИМАЕТ РАБОТУ и уже всё целиком - сдаёт на продуктив.. Т.е. ответственность не может быть колхозная - она всегда исключительно индивидуальная

(58) о чём и речь.. должен быть именно ОТВЕТСТВЕННЫЙ, а не пытаться "хранилище умное, само всё разрулит"

(60) Блин, я и не хочу что хранилище само всё "разрулило"
(58) А где ему это всё склеивать? Разве не в хранилище?

(61)В своей конфе подключенной к хранилищу сначала тестировать все со всех сторон перед тем как кидать в рабочую базу

(51) никак не коррелирует с (62)

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

(64) По сути сейчас так и происходит

(63)Это разные варианты решения проблемы:-)

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

(66) Взаимоисключающие друг друга

(64) это не реально.. ты не можешь вносить изменения в "предыдущую версию" даже если именно эта версия "только для внесения ошибок". Ты всегда будешь и исправлять ошибки и вносить новое только в "последний релиз"

(53) Лишение премии :)

К хранилищу есть вопросы и претензии. Регулярно тема поднимается на партнерском.
Насколько я помню - стандартные ответы 1с: пользуйтесь, что дают + если нас устраивает, то и вас устраивает + основное направление развития это пользователи. Интересы разработчиков вторичны

(67) всё опять возвращается на уровень - "Должен быть ответственный, который всё склеивает и только он помещает всё на продуктив"

(69) Стабильная - Рабочая, Замороженные изменения - хранилище, Новая версия - Другое хранилище
(67) По другому не получается, когда разработка одного блока ведется по несколько месяцев

(70) Это более правильно :). И такие санкции есть

(72) теперь мне лучше понятно что вы хотите, ваше желание обоснованно, но ничего готового нет.

(74) Емнип, Белов (одинэсия) прикрутил 8.1 к cvs.

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

(76) еще году в 2005 видел unpacker, который разбирал конфигурацию 8.0. Возможно что-то на его основе... (с возможностью сборки)

Было бы идеально прикрутить к 1С-ке например Mercurial

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

(76) вроде он вел проект по сборке/разборке 1CD. не взлетит? :-)