Коллеги, у меня такой вопрос — имеет ли смысл писать свою систему контроля версий внутри приложения по управлению метаданными?
Опишу кратко ситуацию.
Есть проект, клиент-серверное десктоп приложение, в котором люди создают какие то свои метаданные (справочники, документы, древовидные структуры, перекрестные связи между ними).
Главной фишкой этого проекта является версионирование этих данных. Отцы проекта пошли по пути создания своей встроенной системы версионирования: это таблички в БД аля ObjectVersion, Brunch, и все все вытекающие проблемы и баги.

А между тем есть более простое решение — использование файловой системы версионирования, и отказ от хранения данных в БД.
Например JetBrains MPS — тоже система метаданных, но они в качестве системы контроля используют SVN (а можно даже CVS).

Сложность в том, что я не могу найти сильной аргументации отказаться от такой самодельной системы контроля версий.

Кстати, а нет ли готовых решений, которые версионируют не просто файлы, а данные? И чтобы не было жесткой привязки к UI. Ну т.е. выходит нужна БД с поддержкой контроля версий. Или это полный бред и никому это не надо?

Здравствуйте, barn_czn, Вы писали:

_>Коллеги, у меня такой вопрос — имеет ли смысл писать свою систему контроля версий внутри приложения по управлению метаданными?
_>Опишу кратко ситуацию.
_>Есть проект, клиент-серверное десктоп приложение, в котором люди создают какие то свои метаданные (справочники, документы, древовидные структуры, перекрестные связи между ними).
_>Главной фишкой этого проекта является версионирование этих данных. Отцы проекта пошли по пути создания своей встроенной системы версионирования: это таблички в БД аля ObjectVersion, Brunch, и все все вытекающие проблемы и баги.

_>А между тем есть более простое решение — использование файловой системы версионирования, и отказ от хранения данных в БД.
_>Например JetBrains MPS — тоже система метаданных, но они в качестве системы контроля используют SVN (а можно даже CVS).

_>Сложность в том, что я не могу найти сильной аргументации отказаться от такой самодельной системы контроля версий.

_>Кстати, а нет ли готовых решений, которые версионируют не просто файлы, а данные? И чтобы не было жесткой привязки к UI. Ну т.е. выходит нужна БД с поддержкой контроля версий. Или это полный бред и никому это не надо?

Отцы могут быть правы, Вы ничего не написали об объеме и числе записей. К тому же в СУБД есть фишки, которые придется реализовывать для ФС. Опять же, служба поддержки, если их навыки заточены на СУБД, трудно будет менять привычки. Это за БД.
За ФС. Да, очень хороша для разработки. А будет ли необходимость пользователю поиметь несколько версий одного объекта? Опять же хранение патчей предпочтительней, чем хранение почти одинаковых данных. Тут тоже есть моменты, которые могут испортить настроение .

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

Здравствуйте, barn_czn, Вы писали:

Сделать промежуточный абстрактный слой для сохранения данных и потом можно будет лепить адаптеры либо для своей системы хранения, либо для каких-то сторонних систем.

Спасибо за отклик.
Что такое ФС? )
Видите ли, я не зря в самом начале сказал что проект — управление метаданными. Поэтому почти нет случаев где требуется две разных версии одного и того же объекта. А значит зачем фичи БД? Есть еще один аргумент. Сорцы любой более менее большой программы — это тоже своего рода метаданные. Вы никогда не задумывались почему до сих пор нет систем контроля версий, которая разлагает код на элементы AST. Я имею ввиду то чтобы хранить код в виде дерева: вершина if — отдельный объект, for — отдельный. Т.е. разложить весь код до примитивов.

Вопрос про размер данных. Да какая разница? Сорцы больших проектов занимают мегабайты. Метаданные — это сорцы.

Здравствуйте, _Obelisk_, Вы писали:

_O_>Здравствуйте, barn_czn, Вы писали:

_O_>Сделать промежуточный абстрактный слой для сохранения данных и потом можно будет лепить адаптеры либо для своей системы хранения, либо для каких-то сторонних систем.

Коллега, полностью согласен! Вопрос в том как имплементить тот слой что отвечает за версионирование. Как убедить "отцов" не лепить свой второй корявый SVN.

Здравствуйте, barn_czn, Вы писали:

b> Сложность в том, что я не могу найти сильной аргументации отказаться от такой самодельной системы контроля версий.

ИМХО, в ней нет принципиально ничего плохого (за исключением "самопала" и изобретения очередного велосипеда). Например, есть такой проект как Fossil, который вполне успешно хранит версии в базе данных.

Здравствуйте, barn_czn, Вы писали:

_>Коллеги, у меня такой вопрос — имеет ли смысл писать свою систему контроля версий внутри приложения по управлению метаданными?

У меня такой ответ — нет. Для другого ответа данных недостаточно.

Здравствуйте, barn_czn, Вы писали:

_>Спасибо за отклик.
_>Что такое ФС? )

Файловая система.

_>Видите ли, я не зря в самом начале сказал что проект — управление метаданными. Поэтому почти нет случаев где требуется две разных версии одного и того же объекта. А значит зачем фичи БД? Есть еще один аргумент. Сорцы любой более менее большой программы — это тоже своего рода метаданные. Вы никогда не задумывались почему до сих пор нет систем контроля версий, которая разлагает код на элементы AST. Я имею ввиду то чтобы хранить код в виде дерева: вершина if — отдельный объект, for — отдельный. Т.е. разложить весь код до примитивов.

Да, что хранить тоже имеет значение. Если исходники, тогда действительно, уже все реализовано.

_>Вопрос про размер данных. Да какая разница? Сорцы больших проектов занимают мегабайты. Метаданные — это сорцы.

Видимо перед Вами не стоит проблема ограничения количества и объема хранимых данных.

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

Здравствуйте, barn_czn, Вы писали:

_>Коллеги, у меня такой вопрос — имеет ли смысл писать свою систему контроля версий внутри приложения по управлению метаданными?
_>Есть проект, клиент-серверное десктоп приложение, в котором люди создают какие то свои метаданные
_>(справочники, документы, древовидные структуры, перекрестные связи между ними).
"метаданные" понятие размытое. CVS работает с текстовым файлом и примерно представляет себе его семантику, ибо у текстового файла она простая. а вот у ms office документов -- есть сложная внутренняя структура -- типа FAT'а в ранних версиях и xml в поздних. простое побайтового сравнение файлов не позволяет сделать вывод об их неидентичности.

смысл делать свою систему есть только в том случае если вам известен формат документа и вы можете его корректно распарсить. в противном случае CVS поедет крышей и будет ничем не лучше хранения копий в db.

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

_>Кстати, а нет ли готовых решений, которые версионируют не просто файлы, а данные?
_>И чтобы не было жесткой привязки к UI. Ну т.е. выходит нужна БД с поддержкой
_>контроля версий. Или это полный бред и никому это не надо?
Это не бред. это широко распространено и это есть у многих офисных приложений. у любой нормальной системы докуменооборота на предприятии есть зашитый контроль версий. на тот случай если вася в день увольнения решит удалить все на хрен, то он не сильно омрачит админа. у кучи сетевых сервисов (если нужно делать на уровне сетевого сервиса), в REST'е PUT обновляет объект, перемещая старый объект на хранение в БД, удаляя его, скажем, через месяц или год. DELETE не удаляет объекты, а только помечает их удаленными. реализуется за один вечер и отлаживается за остаток ночи.

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

Здравствуйте, barn_czn, Вы писали:

_>Коллега, полностью согласен! Вопрос в том как имплементить тот слой что отвечает за версионирование. Как убедить "отцов" не лепить свой второй корявый SVN.

Чтоб убедить "отцов", надо знать больше в чем суть вашего продукта и каковы дальнейшие планы по его развитию. В общем и целом, интеграция с различными системами контроля версий (или БД) есть всегда плюс. Вообще, чем лучше продукт интегрируется с другими — тем лучше.