|
Navision это не среда для одновременной разработки большим количеством сотрудников сложного функционала, поэтому такие вещи как средства для хранения кода во внешних файлах, возможность прикручивания другой IDE, а тем более возможность бренчинга и поддержки версионности (хотя бы на уровне Check In и Check Out) разработчиками просто не были предумотрены.
Больше того, если посмотреть политку лицензирования, становится понятно, что каждый объект стоит определенных денег, поэтому проще изменить(поправить) логику уже существующего объекта, чем быстренько создать новую форму или прикрутить пару-тройку универсальных библиотек кода (стиль высоуровневых языков)
С одной стороны и по большому счету это правильно: лишние фишки, абсолютно не нужные конечному пользователю лишь неоправданно повысили бы цену(себестоимость) решения. С другой стороны - очень редко большое количество программистов работают с единой функциональностью и сталкиваются с необходимостью бренчить версии и отслеживать какой именно кодер изменил определенную строчку кода.
Именно поэтому, Navision изначально не имеет средств, позволяющих его сопрягать с системами контроля версий типа Source Safe, у него даже внутренняя архитектура другая - код хранится не в виде файлов, а в откомпилированном виде в системной таблице.
Версионность существует лишь на уровне объектов, и то при условии неукоснительного соблюдения разработчиками стандартов программирования Navision. Большей частью эта версионность нужна для правильного наката функционала с одной базы (допустим с локальной, в которой идет разработка) в другую (рабочую).
Есть конечно разработки вроде того же NCT, только вот сильно сомневаюсь, что ей практически кто-то пользуется - слишком уж примитивно
|