OberonCore
https://forum.oberoncore.ru/

Контроль актуальности версий используемых компонент.
https://forum.oberoncore.ru/viewtopic.php?f=23&t=3304
Страница 1 из 2

Автор:  Пётр Кушнир [ Четверг, 03 Март, 2011 22:26 ]
Заголовок сообщения:  Контроль актуальности версий используемых компонент.

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

Допустим, в совместной разработке находятся подсистемы А, Б, В. Средство контроля версий используется регулярно. В целом, можно считать, что исходный код (Mod) и ресурсы (Rsrc) синхронизированы, документацию не рассматриваю. Кодовые (Code) и символьные (Sym) файлы исключены из-под контроля версий по соображениям рациональности.

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

Так вот, несмотря на кажущуюся независимость, подсистемы, будучи использованными в одной мега-подсистеме O имеют связи и зависимости друг от друга.

А так как фреймворк следит за соответствием и не даёт вызвать модули, которые скомпилированы для другой версии (т.н. inconsistent import). Имеет проблему рассинхронизации кодовых файлов а не исходного кода.

Коллизия может возникнуть, например, если я развиваю свою подсистему А локально, вношу изменения, приводящие к ii, после этого, я кладу изменения в репозиторий.

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

Затем, ещё кто-то, компилирует подсистему С, от которой зависит А, в свою очередь, коллега опять компилирует подсистему С, при этом, цепочка А-Б оказывается неработоспособной из-за ii.

Покрутив в голове, мы пришли к двум возможным решениям:
  • либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.
  • либо создать систему, которая при компиляции составляла что-либо вроде снимка системы О, журналируя состояние версий модулей и исходников, и которая минимум сигнализировала бы о найденном несоответствии.

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

В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.

Ну и, насчёт хранения кодосимвольных в репе - это не выход, это просто транслирование моей версии всем, но они и так её получат, скомпилировав тут же, по выходу из системы контроля версий

Автор:  Валерий Лаптев [ Четверг, 03 Март, 2011 22:46 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Нужен мейкер в ББ?

Автор:  Пётр Кушнир [ Четверг, 03 Март, 2011 23:10 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пожалуйста, точнее опишите своё предложение.

Автор:  Валерий Лаптев [ Пятница, 04 Март, 2011 08:15 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Не верю, что вы не пользовались мейкером!
В *любой интегрированной среде для С++ такая прога есть обязательно!
А в прежние времена с ней работали из командной строки.

Но все же напишу.
Мейкер - это программа, которая отслеживает временнЫе зависимости файлов-модулей проекта.
Для нее на простом языке пишется файл (текстовый), где прописываются зависимости файлов друг от друга.
Мейкер на основе этой информации запускает трансляцию соответствующих модулей и сборку нового исполняемого модуля.

Автор:  Евгений Темиргалеев [ Пятница, 04 Март, 2011 09:16 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.

Автор:  Info21 [ Пятница, 04 Март, 2011 11:48 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Евгений Темиргалеев писал(а):
Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.
И это, вроде как, обычная практика, no?

Автор:  Пётр Кушнир [ Пятница, 04 Март, 2011 12:49 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

И что, много тут "обычно практикующих" совместную разработку?

Автор:  Info21 [ Пятница, 04 Март, 2011 13:23 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
И что, много тут "обычно практикующих" совместную разработку?
Ну, граница между совместной разработкой и разработкой пары подсистем одним челом не столь однозначная.

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

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

Да и в одной рыхлой подсистеме из многих модулей постоянно имеет место аналогичный эффект.

Точно как Е.Т. предложил: стираешь целиком Com+Sym и перекомпилируешь.

Как я понимаю, роль мейка переходит упорядоченному списку модулей.

Автор:  Александр Ильин [ Пятница, 04 Март, 2011 13:29 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
И что, много тут "обычно практикующих" совместную разработку?
Да найдутся поди.
Пользуюсь GNU Make.
В ББ Com и Sym не стираю, просто завожу коммандер на полную перекомпиляцию подсистемы, и храню его в Docu/Sys-Map.odc. Там же рядом храню и коммандер на выгрузку всех модулей.

Автор:  Info21 [ Пятница, 04 Март, 2011 13:41 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Александр Ильин писал(а):
В ББ Com и Sym не стираю, просто завожу коммандер на полную перекомпиляцию подсистемы ...
Предпочитаю всё-таки стереть Com и Sym из-за того, что бывали накладки какие-то, если не стирать (насколько помню, когда добавляешь модули и т.п.).

Если стереть, то оно само сообщает, если накладка. Проще жить с чистого листа.

Автор:  Пётр Кушнир [ Пятница, 04 Март, 2011 14:08 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.

Автор:  Евгений Темиргалеев [ Пятница, 04 Март, 2011 14:30 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Задачу поставьте конкретнее. Если я правильно понял, это "передать малый пакет изменений системы О на рабочие места". Чтобы посылать не все Code/Sym, а только изменённые.

Могу предложить такое "решение в лоб":
- держать полную копию эксплуатируемой на местах системе
- при появлении изменений, которые надо распространить, строите новую систему
- распространяете разницу, которую выдаст сравнение каталогов.

Автор:  Пётр Кушнир [ Пятница, 04 Март, 2011 15:06 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Задача распространения решена, так или иначе.
Я же не задачи ставлю, я проблему описываю. А мне предлагают УДАЛЯЙ @ КОМПИЛЯЙ.

Автор:  Info21 [ Пятница, 04 Март, 2011 15:08 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
Пётр Кушнир писал(а):
либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.

А. Виноват.

Автор:  Евгений Темиргалеев [ Пятница, 04 Март, 2011 15:19 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
Задача распространения решена, так или иначе.
Я же не задачи ставлю, я проблему описываю. А мне предлагают УДАЛЯЙ @ КОМПИЛЯЙ.
Разве описание проблемы не есть постановка задачи, которой Вы хотите найти (лучшее) решение? Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...

Автор:  Евгений Темиргалеев [ Пятница, 04 Март, 2011 15:29 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

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

И для первой решение "удаляй@компиляй", по-моему вполне нормльное. Зачем ещё чего-то городить.?

Автор:  Пётр Кушнир [ Пятница, 04 Март, 2011 15:43 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

потому что оно ощущается эмпирически. вот, прям в этот момент
Евгений Темиргалеев писал(а):
Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...
Пётр Кушнир писал(а):
В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.
как бы.

Автор:  Пётр Кушнир [ Пятница, 04 Март, 2011 15:46 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Пётр Кушнир писал(а):
потому что оно ощущается эмпирически. вот, прям в этот момент
Евгений Темиргалеев писал(а):
Лично я из первого поста так и не понял толком, в чём заключается самая главная проблема...
Пётр Кушнир писал(а):
В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое.
как бы.

linux-way?

Автор:  Валерий Лаптев [ Пятница, 04 Март, 2011 18:02 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Info21 писал(а):
Евгений Темиргалеев писал(а):
Чем возиться с прописыванием зависимостей в makefile (и тулзу для него), проще сделать удаление Code/Sym и перекомпиляцию с нуля. Скорость компиляции это позволяет.
И это, вроде как, обычная практика, no?

Среди виртовских сред - да. Еще в TopSpeed Modula-2 так делали.
Среди С/С++ и других - нет. Там мейкеры рулят.

Автор:  Info21 [ Пятница, 04 Март, 2011 18:52 ]
Заголовок сообщения:  Re: Контроль актуальности версий используемых компонент.

Валерий Лаптев писал(а):
Info21 писал(а):
И это, вроде как, обычная практика, no?
Среди виртовских сред - да. ..
А мы не про ББ? П.К. на ББ, кажись, работает. Что-то я запутался ...

Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/