обходные за отсутствие контроля версий разветвлений поддержки в Enterprise Architect

Question

Из руководства пользователя

В настоящее время, Enterprise Architect не поддерживает версию Ветвления управления. Для некоторых продуктов, контролирующих версию, могут быть созданы рабочие места для достижения аналогичных результатов; обратитесь в службу поддержки Sparx.

Доступный мне канал поддержки не очень отзывчивый, поэтому давайте посмотрим, что должно сказать об этом. В принципе, я хочу управлять своей моделью так же, как я управляю продуктом, который он моделирует, поэтому, когда мой репозиторий продукта разветвлен, я хочу, чтобы модель была связана с ним. Каковы разные способы борьбы с этим? За и против?

Answer 1

Прежде всего: модель не является кодом. Трудность с моделью (в формате XMI) заключается в том, что она выглядит читаемой, но на самом деле это не так. Поэтому проблема связана с слиянием. В то время как слияние кода создает очевидные результаты (ошибки компилятора из-за неудачных слияний могут быть исправлены более или менее легко) неправильное слияние для модели просто создает мусор. По этой причине вы не можете разветвлять и объединять модель.

Теперь, как вы можете это сделать? Как сказано: нет простого решения. Один из способов - создать отдельные репозитории для каждой ветки. Пока филиалы живут независимо, вы в порядке. Но как вы можете объединить изменения от одной ветви к другой? Грустно сказать, но единственный способ я могу рекомендовать его ручной. На самом деле нет инструмента для сравнения с UML-моделями. Вам нужно найти изменения в пакете и экспортировать этот пакет.

• Если (и это невозможно объяснить в нескольких предложениях) изменения только локальные для этого пакета вы можете импортировать изменения с помощью простого импорта XMI.

• Если вы можете найти изменения для отдельных элементов, вы можете создать фиктивный пакет, временно переместить эти элементы в этот пакет и переместить его. Это будет обновлять элементы в другой ветке, но также перемещать их из исходной позиции (как и в первой ветке), и вам нужно переместить элементы обратно туда, где они были в обеих ветвях, и избавиться от фиктивного пакета.

• В случае структурных изменений вы, вероятно, лучше сделаете изменение вручную в другой ветке и получите обзор.

Подводя итог: ветви модели - это то, с чем вы не хотите работать. Ищите альтернативные способы. Лучшее, вероятно, будет иметь все в одной модели и найти способы пометить ветви внутри модели, используя структуры пакетов, помеченные значения или что угодно. Нелегко справиться.