Контроль версий с процессором Expert Projects

Использование системы контроля версий для разработки программного обеспечения сегодня является стандартной процедурой. Хотя для «стандартных» проектов Eclipse все достаточно ясно, для проектов Processor Expert это не так просто. Я использую проекты Processor Expert с  Git  и  SVN (Subversion) . Я хочу поделиться здесь советами, как использовать проекты Processor Expert с системой контроля версий. Снимки экрана и словарь предназначены для  TortoiseGit  и  Git , но применимы к любой другой VCS (системе контроля версий).

Для контроля версий или игнорирования, вот в чем вопрос

В этом  предыдущем посте  я предоставил разбор различных файлов в проекте CodeWarrior Eclipse and Processor Expert. Существует два важных типа файлов, о которых следует знать в контексте системы контроля версий:

1. Производные файлы : это файлы, созданные или созданные / полученные из источников. Я не хочу, чтобы они были в системе контроля версий, так как я могу создавать их с моими исходными файлами. Поэтому мне нужно  «игнорировать»  их для контроля версий.
2. Непроизводные файлы : это все файлы, которые мне нужны для создания моего проекта, в основном исходные файлы и заголовочные файлы, а также файлы компоновки и любые другие файлы, которые не являются   производными. Я определенно хочу, чтобы их поставили под контроль версий.

Я использую здесь систему контроля версий для разработки программного проекта, а не для того, чтобы поставить результат проекта (например, конечный двоичный файл приложения) под контроль версий. Поэтому я сохраняю в хранилище только то, что необходимо для создания выходных файлов, но  не  выходной файл и производные файлы (сгенерированные объектные файлы и т. Д.). Я могу восстановить производные файлы, поэтому хранение как исходных файлов, так и объектных файлов в системе создает избыточность. А хранение дублированной информации будет источником ошибок.

 Может иметь смысл хранить * все * в системе контроля версий в конце проекта (например, включая используемый компилятор и библиотеки), но это будет другой вариант использования, который здесь не рассматривается. Я работал над проектами, в которых во время разработки в системе контроля версий хранились только исходные файлы, но во время выпуска (выпуск для клиента) * все * хранилось в другой системе контроля версий, включая образ жесткого диска компьютера ПК. создание окончательной сборки. И сборочная машина для ПК тоже была помещена в безопасное место. Требовалось иметь возможность построить то же самое спустя 10 лет. Поскольку в этот период времени операционная система / компилятор хоста, скорее всего, изменится или вообще не будет доступна, было принято решение «контролировать версию». Твердые основные вещи 

Для проекта под управлением версией это означает, что файлы «не производные» (или «исходные») находятся под управлением версией, а все остальное должно быть «проигнорировано». Важно, чтобы у другого разработчика была возможность «проверить» проект из системы, и благодаря этому он может использовать и создавать этот проект.

 Хороший тест — попросить другого инженера «вытащить» ваш проект из репозитория и собрать его: если это возможно, то все в порядке. Если нет, то, возможно, настройки пути являются локальными для моей машины (плохо, плохо, плохо!), Или я пропустил фиксацию файлов. Это похоже на резервное копирование: пока вы действительно не восстановите образ резервной копии, вы не можете быть уверены, что все работает 

Ниже показан проект CodeWarrior Processor Expert (Kinetis), использующий TortoiseGit: файлы и папки с зеленой галочкой находятся под контролем версий, а остальные файлы — нет, поскольку они созданы или получены:

 Для Git у меня есть игнорируемые файлы, перечисленные в файле с именем .gitignore. Для SVS это будет .cvsignore. Другие системы контроля версий используют аналогичные способы.

Эксперт по процессорам и контроль версий

Поэтому мне нужно знать, что игнорировать и что ставить под контроль версий.

Файл / каталоги игнорировать (НЕ помещать в систему контроля версий):

• Документация : эта папка создается Processor Expert.
• FLASH : это имя папки может отличаться для каждого проекта. Он содержит файлы make, сгенерированные системой сборки Eclipse, и все сгенерированные двоичные файлы объектов и приложений.
• Generated_Code : в эту папку Processor Expert помещает все сгенерированные исходные файлы
• .cwGeneratedFileSetLog : этот файл создан мастером проекта CodeWarrior и, насколько мне известно, не используется. Обычно я сразу удаляю этот файл, так как он не используется.
• .ProcessorExpert.g_c  и  .ProcessorExpert.g_x  используются Processor Expert для отслеживания генерации кода, сгенерированного в Generated_Code . Поэтому они мне не нужны в системе контроля версий.
• SaAnalysispointsManager.apconfig : Этот файл используется  SA (Software Analysis) , и его тоже можно игнорировать.

Processor Expert сгенерировал файл памяти и компоновщика

Processor Expert может создавать файлы для отладчика и компоновщика: файл карты памяти для отладчика и файл компоновщика для компоновщика. Это настраивается на вкладке «Параметры сборки» компонента ЦП:

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

Примечание. Даже если файлы памяти и компоновщика сгенерированы, может иметь смысл иметь их в системе управления версиями: файлы представляют собой текстовые файлы (которые легко различать), и они редко изменяются.

Многопользовательская разработка с Processor Expert

Одним из самых больших преимуществ использования системы контроля версий является сотрудничество с другими разработчиками. Система контроля версий может различать и объединять изменения от нескольких разработчиков (или ветвей). Но это хорошо работает только с текстовыми файлами. Если вы хотите одновременно редактировать двоичные файлы, то обычно это не поддерживается.

 В Subversion (SVN) я могу заблокировать файл, внести изменения, а затем зафиксировать бинарный файл с разблокировкой. Это предотвратит параллельное изменение другого разработчика. К сожалению, такая блокировка невозможна в Git (или я не узнал, как это сделать).

Processor Expert (по крайней мере, до MCU10.3) сохраняет все настройки компонентов в одном файле XML: Файл ProcessorExpert.pe представляет собой текстовый файл XML:

Хотя этот XML-файл является текстовым файлом (таким образом, может обрабатываться системой контроля версий), он не должен редактироваться вручную (если вы не являетесь экспертом по XML   ). Проблема заключается в том, что если два пользователя параллельно вносят изменения в этот файл, объединение обычно не очень сложно.

 Технически слияние было бы возможно. Но поскольку Processor Expert создает конфликты (изменяя одинаковые строки для каждого пользователя), это приведет к конфликтам слияния. И эти конфликты слияния повредят XML, если вы не очень, очень осторожны.

Конфликты и ProcessorExpert.pe

Просто предположим, что два разработчика работают параллельно над одним и тем же проектом Processor Expert и параллельно вносят изменения в Processor Expert:

1. И Джим, и Джо проверили одну и ту же версию.
2. Джим добавляет   компонент BitIO и фиксирует изменение.
3. Джо добавляет  светодиодный  компонент и хочет его зафиксировать.
4. Фиксация Джо терпит неудачу, поскольку есть конфликты:

Это создает конфликт, потому что Processor Expert изменял одну и ту же строку в обеих ветках:

Таким образом, Processor Expert хранит счетчик в файле .pe (ааааа!). Конечно, это будет отличаться для каждого поколения кода, вызывая ненужные конфликты. Но не только это, Processor Expert сохраняет другую информацию, такую ​​как имя пользователя и дату, в файл XML, создавая постоянный источник конфликтов системы контроля версий:

Вышеуказанное изменение будет легко объединить. Но разница между компонентами BitIO и LED гораздо сложнее: существует конфликт между BitIO и LED:

Теперь этот будет действительно трудно объединить   .

 Еще хуже: если ваша система контроля версий пытается объединить два файла, полученный XML-файл будет поврежден, что приведет к странным ошибкам в Processor Expert.

Так зачем беспокоиться о конфликте? Особенно новые пользователи с системами контроля версий склонны просто игнорировать конфликт или даже помечать его как «разрешенный». Дело в том, что это сильно укусит тебя. Для моего случая выше, я получу следующее состояние конфликта в моем каталоге:

Система контроля версий пометила файл с восклицательным знаком и попросила меня разрешить конфликт. Я не могу просто проигнорировать это, потому что этот файл XML был изменен:

Без слияния вручную этот файл не будет использоваться с Processor Expert:

Failed loading file ProcessorExpert.pe
Resource is out of sync with the file system: '/Frdm/ProcessorExpert.pe'.
Failed loading file ProcessorExpert.pe
Error on line 31: The content of elements must consist of well-formed character data or markup.

В настоящее время, вероятно, сейчас лучше всего выполнить операцию «возврата» с системой контроля версий и восстановить предыдущую версию этого файла   .

Дилемма с ProcessorExpert.pe

Поскольку Processor Expert хранит все в этом одном XML-файле, а каждое изменение в настройках Processor Expert приведет к изменению, которое, скорее всего, вызовет конфликт, этот XML-файл в значительной степени должен обрабатываться как двоичный файл. Это означает, что мне нужно «заблокировать» и «разблокировать», если я хочу внести изменения. И что я должен сериализовать изменения в этом файле.

 Если бы Processor Expert использовал разные XML-файлы для каждого компонента или «домена настройки компонента», это значительно уменьшило бы вероятность конфликтов. Например, если бы были XML-файлы для каждого компонента, включая компонент ЦП, и если несколько пользователей не меняют один и тот же компонент, все будет работать намного лучше.

Чтобы избежать этого конфликта, есть несколько вариантов:

1. Только один владелец : только один человек должен вносить изменения в файл ProcessorExpert.pe. Это работает довольно хорошо в небольших командах.
2. Очистить для изменения : если кому-то нужно внести изменение, он объявляет запрос на изменение остальной части команды. Это позволит другим зафиксировать ожидающие изменения (если и). Как только запрос удовлетворен, изменение фиксируется, и все извлекают изменения из системы.

 Я могу установить файл ProcessorExpert.pe только для чтения из проводника Windows. Это помешает Processor Expert написать это.

Установка для файла ProcessorExpert.pe только для чтения предотвратит его изменение Eclipse / CodeWarrior. Я все еще могу «сохранить» модификацию, и не будет никакого сообщения об ошибке. Вместо этого ошибка будет записана в виде сообщения в представлении консоли Processor Expert:

Failed saving project file ProcessorExpert.pe
File /Frdm/ProcessorExpert.pe is read-only.

Сохраненный файл эксперта процессора

Если я изменяю настройки в компоненте Processor Expert, это помечается звездочкой (*), как и для любых других представлений Eclipse:

 Используйте CTRL-S (для сохранения), чтобы сохранить настройки компонента

Я видел, что могут быть проблемы, если настройки не были сохранены, и я делаю обновление / извлечение с помощью системы контроля версий для базового файла ProcessorExpert.pe.

 Похоже, что Processor Expert не знает, что основной XML-файл был изменен или, по крайней мере, не каждый раз. Поэтому, если я получаю обновленный файл ProcessorExpert.pe через систему контроля версий, настройки, показанные в Eclipse, не отражают это. Еще хуже: если в Eclipse были внесены несанкционированные изменения, а затем сохранены мои настройки, новая версия из системы управления версиями будет перезаписана. Если я зафиксирую этот новый файл, неправильный файл будет зафиксирован в хранилище.

Таким образом, возможно, что Eclipse / Processor Expert не показывает содержимое файла на диске, а скорее «кэшированную» версию в ОЗУ. Как следствие, я всегда сохраняю свои настройки перед выполнением операции контроля версий, чтобы обеспечить целостность данных (например, с помощью кнопки «  Сохранить все» ).

Рекомендуемый процесс

Я рекомендую следующий процесс для работы с Processor Expert под управлением версиями в среде групповой разработки, где несколько пользователей могут изменять параметры компонента Processor Expert:

1. Разработчик, который хочет внести изменение, получает «блокировку» для файла ProcessorExpert.pe. Либо через блокировку в системе контроля версий (если поддерживается, например, в SVN), либо путем общения с другими разработчиками.
2. Он вносит изменения и закрывает проект, чтобы обеспечить запись файла XML на диск.
3. Он фиксирует изменение и заново открывает проект в своей рабочей области.

Чтобы избежать неправильного обновления ProcessorExpert.pe, необходимо выполнить следующие действия для системы управления версиями «pull»:

1. Закройте проекты Processor Expert (меню «  Проект»> «Закрыть проект» ), чтобы сохранить настройки.
2. Сделайте «тянуть». Это обновит локальные файлы.
3. Снова откройте проект Processor Expert (меню «  Проект»> «Открыть проект» ), чтобы убедиться, что информация о Processor Expert загружена.

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

Резюме

Использование Processor Expert с системой контроля версий не очень просто. Тот факт, что Processor Expert хранит все свои важные настройки в большом XML-файле, затрудняет сотрудничество в команде разработчиков. Единственный подходящий способ работы с файлом ProcessorExpert.pe — это в значительной степени обрабатывать его как двоичный файл. Это требует осторожности и осознания того, что любые конфликтующие изменения могут легко привести к беспорядку. Лучше координировать изменения файла ProcessorExpert.pe в команде, чтобы эти изменения были сериализованы. И чтобы убедиться, что настройки / проект всегда сохраняются на диск перед выполнением операций контроля версий, а затем перезагружаются. Поэтому ключ заключается в том, чтобы сериализовать изменения в Processor Expert

Использование системы контроля версий в единой среде разработчика не является проблемой, и уже приносит большую пользу. Знание механики, лежащей в основе этого, и того, какое значение имеют проекты Processor Expert, позволит избежать многих разочарований (и поврежденных проектов). Но как Processor Expert хранит в настоящее время (по крайней мере, до CodeWarrior MCU10.3) свою информацию, он не предназначен для работы с системой контроля версий «из коробки». Но я надеюсь, что с помощью приведенных выше советов можно избежать ловушек и ловушек, и что в будущем Processor Expert выпускает и изменяет вещи, что делает систему управления версиями дружественной.

Счастливого Версионирования