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

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

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

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

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

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

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

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

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

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

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