[Devel] [Задача 6208] Контроль и принятия изменений в репозитории Яуза

Evgeny Sinelnikov sin на etersoft.ru
Ср Ноя 24 16:08:38 MSK 2010


24 ноября 2010 г. 15:15 пользователь Pavel Vaynerman <pv на etersoft.ru> написал:
> Среда 24 ноября 2010, Evgeny Sinelnikov написал:
>> 24 ноября 2010 г. 13:50 пользователь  <bugs на lists.etersoft.ru> написал:
>> > http://bugs.etersoft.ru/show_bug.cgi?id=6208
>> >
>> > Pavel Vainerman <pv на etersoft.ru> changed:
>> >
>> >           What    |Removed                     |Added
>> > -------------------------------------------------------------------------
>> > --- Hours Worked|                            |0.07
>> >
>> > --- Comment #26 from Pavel Vainerman <pv на etersoft.ru> 2010-11-24 13:50:33
>> > MSK ---
>> >
>> >> К сожалению, гигантский связный configure.xml принципиально подвержен
>> >> коллизиям. В идеале, стоит делегировать его правку кому-то одному.
>> >
>> > Это не реально. Это основной файл - для всех алгоритмов,
>> > и замыкать работу на одного - невозможно.
>> >
>> > P.S. У меня была идея (пока только умозрительная), делать конфигурацию
>> > в БД (MySQL например). А потом генерировать configure.xml.
>> > Ну а другая.. в приенципе использовать SQLite.
>>
>> По моему разбить файл на несколько файлов - более простой и надёжный
>> вариант. База данных, в итоге, тоже хранит таблицы в отдельных файлах,
>> блобах и т.п.
> ...
>> По моему, разбить configure.xml файлы и подразумевать под
>> конфигурацией не один файл, а каталог проще и надёжнее. При этом
>> отдельные файлы и править легче и потенциальные конфликты возникать
>> будут только на правке одних и тех же файлов.
>   Помоему тогда начнётся морока с тем, чтобы все эти файлы поддерживать в
> "синхронном состоянии" (по идентификаторам, именам и т.п.). И конфигураторы
> писать в каком-то смысле сложнее...
>

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

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

-- 
Sin (Sinelnikov Evgeny)


Подробная информация о списке рассылки Devel