IPB

Здравствуйте, гость ( Вход | Регистрация )

3 страниц V   1 2 3 >  
Ответить в эту темуОткрыть новую тему
> Одновременное добавление объектов в конфигурацию, Возможные проблемы и способы их решения
Anseis
сообщение Mar 4 2004, 13:36
Сообщение #1


Пользователь
**

Группа: Пользователи
Сообщений: 29
Регистрация: 3-March 04
Пользователь №: 1317



Есть предложение обсудить технологию многопользовательской разработки с учетом возможностей текущей версии openconf_beta и скрипта gcomp.vbs. Для людей работающих непосредственно с конфигуратором предлагаю два варианта:

1. если делаются легкие правки (прамо на боевой конфигурации), то после сохранения md в new_stru забрать его оттуда в локальное дерево распаковать, сделать cvs update -dP, решить вопрос с конфликтами, сделать cvs commit, собрать md, скопировать обратно, вернуть управление конфигуратору.

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

2. для серьезных правок разработчик делает с вою личную копию рабочей базы и её корежит, параллельно с этим делается cvs tag -b (создание новой ветки), затем cvs checkout -r в другую директорию (отличную от п.1) дальше осуществляет все правки по стратегии п.1, но над своей локальной базой и убедившись, что все работает сливает свой локальный репозиторий на ствол генерит новый md и производит штатное обновление конфигурации 1с с заменой всех объектов.

Как вам такая идея, и что я в этом описании упустил.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение Mar 4 2004, 15:04
Сообщение #2


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



Цитата(Anseis @ Mar 4 2004, 13:36)
1. если делаются легкие правки (прамо на боевой конфигурации), то после сохранения md в new_stru забрать его оттуда в локальное дерево распаковать, сделать cvs update -dP, решить вопрос с конфликтами, сделать cvs commit, собрать md, скопировать обратно, вернуть управление конфигуратору.

Единственное что - на боевой базе никакие правки не производятся. Для коллективной разработки - это особенно важно.
В боевую базу загружается версия только из репозитория.

Цитата
В этом варианте меня смущает то, что если кто-то внес изменения в репозитарий, то мы получим другой md (относительно того, который анализировался на сделаные изменения), правда это маловероятно.


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

Цитата
2. для серьезных правок разработчик делает с вою личную копию рабочей базы и её корежит, параллельно с этим делается cvs tag -b (создание новой ветки), затем cvs checkout -r в другую директорию (отличную от п.1) дальше осуществляет все правки по стратегии п.1, но над своей локальной базой и убедившись, что все работает сливает свой локальный репозиторий на ствол генерит новый md и производит штатное обновление конфигурации 1с с заменой всех объектов.


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

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


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Anseis
сообщение Mar 4 2004, 15:11
Сообщение #3


Пользователь
**

Группа: Пользователи
Сообщений: 29
Регистрация: 3-March 04
Пользователь №: 1317



Цитата(fez @ Mar 4 2004, 15:04)
Есть один аспект, связанный с добавлением в конфигурацию новых объектов, имеющих внутренний идентификатор (справочник, документ, регистр, константа, реквизит, форма журнала, форма списка справочника, etc).

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

Желание есть и большое.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
artbear
сообщение Mar 4 2004, 17:09
Сообщение #4


Продвинутый
***

Группа: Пользователи
Сообщений: 887
Регистрация: 25-July 03
Из: Башкортостан
Пользователь №: 13



(fez) Излагай!


--------------------
[span style='color:blue']Эх, дайте что-нибудь новенькое да полезное потестить ;-)[/span]
[span style='color:blue']1C++ developer :)[/span] www.1cpp.ru
[span style='color:blue']OpenConf developer :: [/span] openconf.itland.ru
[span style='color:blue']FormEx developer :)[/span] formex.dorex.ru
[span style='color:blue']1C++ active tester :)[/span] www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение Mar 5 2004, 02:29
Сообщение #5


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



В общем так.

0. Что вообще такое - конфликт идентификаторов?
Это когда в разных конфигурациях один идентификатор принадлежит разным по своей сути объектам.

1. Зачем его надо избегать?
Если в разных конфигурациях нет конфликта по внутренним идентификаторам - мы можем смело пользоваться любой объединялкой каталогов для объединения. Полученная в результате конфигурация нормально (без потерь данных) загрузится как измененная во всех предшественников.

2. Небольшое отступление в сторону.
Что происходит, когда в конфигурацию добавляется объект, требующий дентификатора? Происходит ровно две вещи.
а) В соответствующее место MainMetadataStream добавляется строчка с описанием объекта
б) В шапке MainMetadataStream (после разборки GComp 2.0 и старше посмотрите в файл ИдентификаторыКонфигурации.mdp - это там) есть место, где прячется первый свободный идентификатор. Туда прибавляется единица.

3. Дальше - все просто.
Представим для простоты, что у нас всего два разработчика. И обоим нужно условно одновременно добавлять идентификаторы в конфигурацию.
Задача Первого - определить, сколько идентификаторов ему нужно добавить. Назвать большее число - не страшно, страшно назвать меньшее.
Второй, после того, как сделает cvs checkout и перед тем, как приступить к работе - должен произвести небольшое шаманство. Он лезет в ИдентификаторыКонфигурации.mdp, и там прибавляет к текущему последнему идентификатору - число, названное Первым разработчиком.
Теперь задача Первого - ни коммитить, ни апдейтить свой ИдентификаторыКонфигурации.mdp, чтоб не затерлось. И тщательно следить за тем, чтобы количество добавленных им идентификаторов не превысило названной им же величины.
Если он видит, что превышает - операция по выделению следующего диапазона идентификаторов повторяется.

Эту же технику можно применить как к большему числу разработчиков, так и к вопросу обновления типовых, в которые вносятся сторонние изменения. Перед внесением этих самых изменений - устанавливаем в ИдентификаторыКонфигурации.mdp - 100000. Учитывая, что за 4 года разработчики типовых для 7.7 дошли только до 38000 - запаса хватит еще года на три, как минимум. А к тому времени ишак точно сдохнет.
Теперь можно смело добавлять объекты в типовую, а про объединение конфигураций забыть, как про страшный сон.


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RealChel
сообщение Mar 23 2004, 09:50
Сообщение #6


Пользователь
**

Группа: Пользователи
Сообщений: 85
Регистрация: 28-August 03
Из: Челябинск
Пользователь №: 431



Цитата(fez @ Mar 5 2004, 02:29)
Он лезет в ИдентификаторыКонфигурации.mdp, и там прибавляет к текущему последнему идентификатору - число, названное Первым разработчиком.

{"MainDataContDef","15359","10009","7120"}
А какой из них идентификатор

Сообщение отредактировал fez - Mar 23 2004, 11:36
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
Anseis
сообщение Mar 23 2004, 10:37
Сообщение #7


Пользователь
**

Группа: Пользователи
Сообщений: 29
Регистрация: 3-March 04
Пользователь №: 1317



Цитата(RealChel @ Mar 23 2004, 09:50)
{"MainDataContDef","15359","10009","7120"}

___________________^^^^
Цитата(RealChel @ Mar 23 2004, 09:50)
А какой из них идентификатор

15359
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RealChel
сообщение Mar 23 2004, 11:26
Сообщение #8


Пользователь
**

Группа: Пользователи
Сообщений: 85
Регистрация: 28-August 03
Из: Челябинск
Пользователь №: 431



Цитата(fez @ Mar 5 2004, 02:29)
Он лезет в ИдентификаторыКонфигурации.mdp, и там прибавляет к текущему последнему идентификатору - число, названное Первым разработчиком.

Как грамотно увеличить идентификатор?
Предположим.
Я получил стабильный релиз.
Пометил ветку разработки.
И собираюсь продолжать разработку с изменением структуры.
И хотелось бы в случае чего влезть в стабильный релиз(если что) и внести изменения.Может даже с добовлением объектов.
Я так понимаю мне надо увеличить последний идентификатор перед тем как продолжать работу над новой версией?

Сообщение отредактировал fez - Mar 23 2004, 11:37
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение Mar 23 2004, 11:44
Сообщение #9


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



Цитата(RealChel @ Mar 23 2004, 11:26)
Цитата(fez @ Mar 5 2004, 02:29)
Он лезет в ИдентификаторыКонфигурации.mdp, и там прибавляет к текущему последнему идентификатору - число, названное Первым разработчиком.

Как грамотно увеличить идентификатор?

ИдентификаторыКонфигурации.mdp можно редактировать в любом текстовом редакторе.

Правда, мне кажется, что это не совсем тот, ответ, которого ты ждешь smile.gif
К сожалению, я не могу дать короткую и исчерпывающую инструкцию на все случаи жизни. Единственное, что могу посоветовать - попытаться понять, зачем нужны эти самые идентификаторы, на что они влияют, и что на самом деле находится в ИдентификаторыКонфигурации.mdp.
Думаю, что после этого ты сможешь задавать более осмысленные вопросы.


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
RealChel
сообщение Mar 25 2004, 06:40
Сообщение #10


Пользователь
**

Группа: Пользователи
Сообщений: 85
Регистрация: 28-August 03
Из: Челябинск
Пользователь №: 431



TO (fez)
Вернемся к идентификаторам объектов.
Я сделал следующее.
Выпустил стабильный релиз.
И перед тем как продолжать увеличил внутренний идентификатор.
Зафиксил все это дело.
Продолжаю разработку.
Теперь если мне надо стабильный релиз то я получаю версию до увеличения идентификатора.Делаю ветку.И в ней что то меняю.
Теперь как мне слить.Из этой ветки в основную.
Я пользуюсь TourtoiseCVS.
Попробовал команду слить.
Потом посмотрел в каталог где уменя MD висит и ездец.
Она мне нах все поудаляла.
Может чего не так сделал.
А с утреца подумал.Может лучше получить этот MD и им обновить основной?
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение Mar 25 2004, 23:37
Сообщение #11


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



(RealChel) Я как-то пока с сомнением отношусь к возможности cvs вливать куски из веток в основной ствол. Там есть масса каких-то своих особенностей, в которых я сам еще не до конца разобрался.

Я советую делать гораздо проще. Есть специализированный инструмент по объединению файлов/каталогов - kdiff3. Формируешь два каталога: каталог с отредактированным релизом, и каталог с development версией. kdiff'ом объединяешь эти каталоги, там все наглядно, и полученный каталог оказывается development версией с влитыми туда изменениями из ветки релиза.


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение May 21 2004, 12:46
Сообщение #12


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



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

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

Грабли вот в чем. Нужно строго различать доработку типовой "в коллективе" с 1С, и реальную коллективную разработку конфигурации.

Разница в этих режимах принципиальная.

1С не знает о Вашем существовании и лепит в своих доработках те идентификаторы, какие ей нравится. Поэтому-то так и важно "разбежаться" с ней раз и навсегда. Например, используя в своих доработках идентификаторы более 100'000, например.

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

Поясняющий пример:

Кодер Вася получил "пожизненный" диапазон идентификаторов от 100 до 199 и создал справочник "Товары", у которого идентификатор 100.
Одновременно с этим кодер Петя получил диапазон от 200 до 299 и создал справочник "Единицы" с идентификатором 200. Оба скоммитили свои изменения в репозиторий.

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

Но тут Вася вспоминает, что он забыл добавить в справочник "Товары" реквизит "БазоваяЕдиница". И вот тут его ждет засада. Ибо присвоить этому реквизиту идентификатор 101 - не получится. В худшем случае будет 201, в лучшем - 300.

Как это у 1С получается, я точно не знаю, но присвоить новому объекту идентификатор с номером меньшим, чем у существующего в конфе объекта - задача нетривиальная.

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

А именно: Вася планирует создать несколько объектов (планирует не дальше, чем на день вперед), и думает, что 10-ти номеров ему хватит. Для начала он делает cvs update для того, чтобы получить последний идентификатор. Потом он изменяет ИдентификаторыКонфигурации.mdp, прибавляя туда 10 и сразу коммитит его в репозиторий. Таким образом он занял интересующий его диапазон идентификаторов.
При этом Вася НЕ делает gcomp -c - в своей разработке он пользуется "старым" ИдентификаторыКонфигурации.mdp.

Если в этот момент Петя захотел добавить объектов, то при cvs update он получит самый последний Васин ИдентификаторыКонфигурации.mdp, несмотря на то, что соответствующих объектов Вася еще не создал.

Вернемся к Васе. У него есть три задачи, на которых он должен сосредоточить свое внимание. Первая - не вылететь за 10 идентификаторов. Вторая - не делать cvs update до тех пор, пока он все не напишет. Третья - при cvs commit не коммитить ИдентификаторыКонфигурации.mdp.

Если Вася вылетит за 10 идентификаторов (допустим, он неправильно оценил потребности 1С по идентификаторам) - ему придется делать всю работу заново с новым, более широким диапазоном ИДшников. После пары-тройки случаев такого попадалова Вася научится точнее определять размеры диапазонов.

Если Вася сделает cvs update, в котором приедут Петины объекты - прежде чем продолжать добавлять свои объекты, Васе придется занять следующий диапазон. Неиспользованную дырку в номерах ИДшников придется так и оставить неиспользованной.

Если Вася сделает cvs commit своего ИдентификаторыКонфигурации.mdp - нужно сразу же восстановить предыдущую ревизию этого файла. Если этого своевременно не сделать - Васе грозит разгребание конфликта идентификаторов, что, как показал опыт anseis'а - задача не из легких.


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
AlexWhite
сообщение May 21 2004, 22:37
Сообщение #13


Пользователь
**

Группа: Пользователи
Сообщений: 34
Регистрация: 29-July 03
Пользователь №: 212



Считаю, что в gcomp надо сделать 1 принципиальную вещь, а именно:
жизненно необходим файл (ОДИН), который должен служить эталоном структуры метаданных.
К "структуре" метаданных, имхо, следует отнести все объекты, которые имеют ИД и, наверное, файл ИдентификаторыКонфигурации.mdp
Когда "эталон" структуры находится в одном файле, разрулить коллективное добавление объектов значительно проще, чем когда структуры разбросаны по разным файлам и разным папкам.
Почему для этих целей не годится файл ИдентификаторыКонфигурации.mdp? Потому, что есть еще объекты, типа Gallery.bmp, которые бинарные и нет возможности через cvs учесть изменения, которые сделаны хотябы двумя разработчиками одновременно.
При наличии такого "контрольного" файла операции над добавлением объектов в конфигурацию должно быть разрешено только тогда, когда добавляющий смог сделать Reserve Edit над этим файлом. Выполнил Reserve Edit, добавил объекты, разобрал новую структуру, получил измененный "контрольный файл", закоммитил, и только после этого спокойно без изменения структуры продолжает работать с формами, модулями. (Кстати, при начале работы с таблицами тоже надо юзать такой порядок, так как это - бинарники) За этим файлом можно назначить watchers, которые при коммите получат сообщение, что файл закоммичен и можно другим добавлять объекты.
Иначе, если пытаться "домысливать" диапазоны ИД, то рано или поздно случится худшее из возможных проблем.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
fez
сообщение May 24 2004, 11:56
Сообщение #14


Сильно пишущий
****

Группа: Пользователи
Сообщений: 2385
Регистрация: 25-July 03
Из: Москва
Пользователь №: 80



Цитата(AlexWhite @ May 21 2004, 22:37)
Почему для этих целей не годится файл ИдентификаторыКонфигурации.mdp? Потому, что есть еще объекты, типа Gallery.bmp, которые бинарные

Ты предлагаешь создать один файл, в котором будут и структура метаданных, и галерея картинок, и моксели? Или я чего-то не понял?

Если я чего-то не понял - тогда объясняй еще раз, почему для этих целей не годится ИдентификаторыКонфигурации.mdp.


--------------------
Я вам тут наговорю...
1c++ developer :: www.1cpp.ru
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения
AlexWhite
сообщение May 24 2004, 16:03
Сообщение #15


Пользователь
**

Группа: Пользователи
Сообщений: 34
Регистрация: 29-July 03
Пользователь №: 212



Цитата
Ты предлагаешь создать один файл, в котором будут и структура метаданных, и галерея картинок, и моксели? Или я чего-то не понял?

Почти правильно. С бинарными файлами можно оговорить в технологии работы, что перед изменением, попробуйте сделать Reserve Edit, а вот с файлами mdp и ord в разных каталогах уследить трудно. Например добавляешь журнал, а у тебя меняется и ИдентификаторыКонфигурации и ПорядокОбъектов.ord в папке журналов и Структура.mdp появляется новый.

Для этого нужен 1 файл, который на время изменения структуры делать его ReserveEdit - сигнал другим "повременить с изменением структуры".
Да и после добавления не все аккуратно вспоминают, что кроме Идентификаторы надо еще пару тройку файлов коммитить, находящихся в других папках по отношению к добавленному объекту.
Вернуться в начало страницы
 
+Ответить с цитированием данного сообщения

3 страниц V   1 2 3 >
Ответить в эту темуОткрыть новую тему
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 



RSS Текстовая версия Сейчас: 18th July 2019 - 04:08