В процессе развития довольно сложных приложений и используемых ими компонент возник концептуальный, на мой взгляд, вопрос.
Допустим, в совместной разработке находятся подсистемы
А,
Б,
В. Средство контроля версий используется регулярно. В целом, можно считать, что исходный код (
Mod) и ресурсы (
Rsrc) синхронизированы, документацию не рассматриваю. Кодовые (
Code) и символьные (
Sym) файлы исключены из-под контроля версий по соображениям рациональности.
В периоды автономной работы, у каждого из разработчиков накапливаются изменения. Для простоты, примем, что каждый разработчик "ведёт" свой компонент, и чужие не трогает, то есть, изменения собственно исходного кода не пересекаются (пересечение, кстати, отдельный момент, есть мысль про diff-плагин для HG).
Так вот, несмотря на кажущуюся независимость, подсистемы, будучи использованными в одной мега-подсистеме
O имеют связи и зависимости друг от друга.
А так как фреймворк следит за соответствием и не даёт вызвать модули, которые скомпилированы для другой версии (т.н.
inconsistent import). Имеет проблему
рассинхронизации кодовых файлов а не исходного кода.
Коллизия может возникнуть, например, если я развиваю свою подсистему
А локально, вношу изменения, приводящие к ii, после этого, я кладу изменения в репозиторий.
Коллега, видит по логу репа, что есть изменения в библиотеке
А, компилирует её сразу, но, при этом не компилирует подсистему
Б, которая от неё зависит, при этом, в достаточно сложной системе может просто отсутствовать возможность быстро проверить работоспособность всех функций. В итоге, в какой-то момент времени, возникает коллизия.
Затем, ещё кто-то, компилирует подсистему
С, от которой зависит
А, в свою очередь, коллега опять компилирует подсистему
С, при этом, цепочка
А-Б оказывается неработоспособной из-за ii.
Покрутив в голове, мы пришли к двум возможным решениям:
- либо, не рассматривать кодовые файлы как нечто постоянное и отважно удалять их, перекомпилируя ВСЮ систему в целом. Что может быть невозможным, при отсутствии исходников, либо, при наличии постоянно развивающихся исходников, либо, окажется неадекватным, вследствие необходимости передать малый пакет изменений системы О на рабочие места.
- либо создать систему, которая при компиляции составляла что-либо вроде снимка системы О, журналируя состояние версий модулей и исходников, и которая минимум сигнализировала бы о найденном несоответствии.
Конечно, у нас есть способ сравнивать кодовые файлы только по коду, и выделять изменённый код, игнорируя метки даты. Тем самым, вариант номер раз вполне реально использовать в ряде случаев. Но он мне кажется скорее хаком, нежели тем, на что можно опереться системно, потому что, если я уже успел наваять ещё изменений в А, то автоматика споткнётся уже на моей стороне.В связи с этим хотелось бы осмыслить проблему вообще. Сформулировать, и всё такое. Ну и, насчёт хранения кодосимвольных в репе - это не выход, это просто транслирование моей версии всем, но они и так её получат, скомпилировав тут же, по выходу из системы контроля версий