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

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


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.
>

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

В чём смысл использования базы? Это ведь уже не будет тогда часть
исходников (разве что бесполезный, для совместной работы, дамп). Смысл
в том, как я понимаю, чтобы дать интерфейс для расширения конфигурации
по заданной схеме.

Главный недостаток базы может быть в том, что связи в XML сейчас
заданы не только структурой вложенных тегов, но и интерпретацией
свойств, заданных в свойствах тегов. Тем не менее это можно обойти,
поскольку свойства всё-таки не базой интерпретируются. Хотя
нормализацию тогда сможет обеспечить только инструмент
uniset-configurator

Мне кажется, что база не подходит по тому как раз, что хотелось бы
хранить конфигурацию в исходниках - так надёжнее, когда git clone даёт
всё, что нужно, чем когда нужно ёще базу подключать. SQLite вообще не
вариант - конфликты принципиально неразрешимы, хотя можно фиксировать
запросы и вместо ручного объединения применять их поверх коллизии.

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

-- 
Sin (Sinelnikov Evgeny)


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