Rational Software Architect и GitHub
Мы используем Rational Software architect для моделирования наших проектов. И у нас есть наш репозиторий в Github для совместной работы среди членов команды. Проблема, с которой мы сталкиваемся при слиянии / конфликтах. Поэтому, если один из членов команды вносит некоторые изменения в модель и фиксирует / подталкивает свои изменения, а другие пытаются осуществить это изменение, возникает много конфликтов.
К сожалению, эти конфликты в основном связаны с изменениями метаданных в файлах.emx, которые RSA создает самостоятельно. Эти конфликты очень трудно разрешить, и они не читаются человеком.
Кто-нибудь еще сталкивался с подобными проблемами при использовании RSA с GitHub
2 ответа
Ваша проблема не в RSA, а в мерзавце. А точнее ваш клиент git.
RSA может выполнять различие или слияние, понятное человеку, оно анализирует семантику содержания различных версий. Но для этого ему нужно, чтобы содержимое не изменялось, не загрязнялось строками "diff", созданными вашим git-клиентом. Это просто ожидать, чтобы иметь оригинальное содержание версии. Большинство систем управления версиями думают, что они способны создавать различные способы, но со сложным контентом они не могут понять семантику.
Если вы возьмете CVS, клиент eclipse просто предоставит полную версию s без изменений и делегирует diff "инструменту rsa diff", и все будет работать нормально.
В настоящее время я ищу решения для той же проблемы, которую вы описали в своем вопросе. Однако в моей компании сам RSA используется для разрешения этих конфликтов слияния. Поэтому предложенные ниже решения не будут работать в полной мере для вас, если вы используете инструмент слияния или редактор, который не может работать с канонизированными файлами XML. Мы наблюдаем те же проблемы, поскольку мы используем Gerrit для проверки кода, и, как вы указали в своем вопросе, исходный код не читается человеком, и поэтому его невозможно просмотреть или прокомментировать в пользовательском интерфейсе Gerrit.
Исходный код, встроенный в документы XML с расширениями имен файлов.efx и.emx, был изменен или канонизирован таким образом, чтобы такие символы, как перевод строки, кавычки и другие, были заменены соответствующими последовательностями в кодировке HTML. Git и Gerrit ожидают, что каждая строка исходного кода завершается переводом строки, поэтому в результате получаются почти бесконечно длинные строки, состоящие из всех строк исходного кода в так называемом сцепленном фрагменте, перемежающемся с некоторыми последовательностями кодирования HTML.
Кто-то в нашей компании, по крайней мере, добавил в git простой фильтр diff, чтобы при вызове "git show", "git diff" и других команд для просмотра содержимого файла встроенные строки исходного кода были удобочитаемыми. Фильтр - это просто набор глобальных операторов поиска и замены, заменяющих примерно дюжину кодированных HTML-последовательностей соответствующими символами UTF-8.
Я считаю, что для решения этой проблемы есть две альтернативы;
1) Добавьте к Gerrit какой-то фильтр, который работает почти так же, как фильтр diff для git, упомянутый выше, заменяя последовательности кодирования HTML на соответствующие символы UTF-8.
2) Добавьте грязные и чистые фильтры, чтобы при проверке кода строки исходного кода конвертировались в UTF-8 внутри комментария HTML, размещенного рядом с строкой, закодированной в HTML. В Gerrit тогда можно будет увидеть исходный код так, как задумал автор, что позволяет просматривать и комментировать как обычно. При извлечении фильтр smudge удаляет комментарий HTML и исходный код внутри него, оставляя.efx и.emx в точности так же, как когда RSA записал содержимое на диск. Хотя это изменит содержимое файла и фактически увеличит вдвое размер, поскольку исходный код повторяется, содержимое останется действительным документом XML, который не должен влиять на RSA, даже если комментарий HTML должен выдержать процесс размазывания.
Недавно я слышал, что последнюю версию RSA 9.1, я считаю, можно настроить так, чтобы встроенный исходный код в файлах фрагментов оставался более или менее неповрежденным, чтобы его можно было просматривать и проверять в Gerrit без необходимости обходных путей, таких как перечисленные выше. Я еще должен подтвердить для себя, действительно ли это работает, как описано.