Использование внешнего контроля версий

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

Необходимость отслеживать изменения, внесенные в файл, в сочетании с потребностью в систематическом решении для управления исходными данными, зафиксированными в электронной форме, привела к появлению систем управления версиями (Version Control Systems, VCS). Системы управления версиями — это программные инструменты, которые не только способны хранить историю различных версий файла, но и поддерживают открытие любой ревизии этого файла, а также сравнение изменений между любыми двумя версиями файла. Как правило, VCS интегрируется с локальной операционной системой (OS), предоставляя дополнительные функции и операции версионирования для папок и файлов.

Системы управления версиями могут работать полностью независимо от среды создания и редактирования, используемой для формирования файла. Обычно они предлагают интерфейс, позволяющий Add, затем Commit файлов в центральную область хранения, называемую репозиторием, функцию Checkout для копирования файла из репозитория в рабочую папку, функцию Commit для возврата любых изменений обратно в репозиторий, способ ведения журнала информации об изменении и многое другое.

Эти возможности доступны в расширениях оболочки Windows, таких как клиент Tortoise client , и также включены в сам Altium Designer. Операции VCS можно выполнять в среде Altium Designer без необходимости обращаться к файловой системе ОС.

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

Основы Version Control

Altium Designer поддерживает системы управления версиями (VCS) Subversion (SVN) и Git. Поскольку эти системы поддерживаются внутренне, Altium Designer предоставляет доступ к общим командам работы с файлами SVN/Git, таким как Commit, Update и т. п., прямо в Altium Designer, а также к дополнительным возможностям Subversion, например к созданию SVN-репозитория. Это интегрируется с функциями сравнения схем и PCB, что позволяет быстро сравнивать и выявлять различия между двумя ревизиями документа схемы или PCB, а для PCB-проектов — разрешать конфликты при параллельном внесении изменений в ревизии.

Базовый подход к работе с системой управления версиями (VCS) заключается в том, чтобы получить из репозитория копию файлов проекта, с которыми вы хотите работать, отредактировать файлы в Altium Designer, а затем «закоммитить» измененные файлы обратно в репозиторий. Взаимодействие с репозиторием осуществляется через интерфейс системы управления версиями, который Altium Designer встроил в свои панели Storage Manager panel  и Projects panel.

Ключевой принцип работы системы управления версиями в том, что она отслеживает состояние файлов, полученных из репозитория через рабочую папку, и тем самым фиксирует, с какой ревизией ведется работа и была ли она изменена. Хотя результат одинаков, организация репозитория и рабочих файлов различается в зависимости от типа системы управления версиями — Git или SVN.

Git VCS

На рисунке ниже показана концепция общего удаленного репозитория Git, который содержит последовательность ревизий файлов проекта (до ревизии 5), при этом его содержимое скопировано в локальный рабочий репозиторий Git — обычно путем клонирования (Cloning) удаленного репозитория или выполнения Pull его данных в рабочий репозиторий. Когда файлы в рабочем репозитории открываются в среде Altium Designer, Altium Designer распознает, что файл проекта находится под управлением версий Git, а его текущий статус управления версиями отображается как в панели Storage Manager, так и в панели Projects.

► Дополнительные сведения см. на странице Git-based Version Control.

Subversion VCS

На рисунке ниже показана концепция репозитория Subversion, который содержит последовательность ревизий файлов проекта (до ревизии 5), при этом последняя копия извлечена (checked out, File » Check Out) в рабочую папку. Когда файлы в рабочей папке открываются в среде Altium Designer, Altium Designer распознает, что файл проекта находится под управлением версий SVN, а его текущий статус управления версиями отображается как в панели Storage Manager, так и в панели Projects.

► Дополнительные сведения см. на странице SVN-based Version Control.

В обеих указанных выше VCS-системах связь между исходным репозиторием и рабочим расположением хранится в VCS-базе данных последнего (в системной подпапке .svn или .git).

Когда рабочие файлы VCS открыты в Altium Designer, контекстное меню по правому щелчку в панели Storage Manager (и в панели Projects) позволяет выполнять стандартные действия VCS, например коммит измененного файла в центральный репозиторий (SVN) или в рабочий репозиторий (Git).

Доступ к Version Control

В Altium Designer действия, связанные с VCS, можно выполнять через панели Projects и Storage Manager, при этом последняя предоставляет прямой доступ к дополнительным командам и информации VCS. Панели заполняются документами проекта и соответствующим статусом VCS при открытии в Altium Designer.

Панели можно открыть из меню кнопки в правом нижнем углу рабочей области или из главного меню View » Panels.

Панель Projects

Панель Projects отображает все проекты, которые в данный момент открыты в Altium Designer, вместе с входящими в них документами и соответствующим статусом Version Control для каждого файла.

Статус файла VCS в панели обозначается набором значков, соответствующих определенным состояниям файла, обнаруженным системой управления версиями. Состояние каждого файла, в общих чертах, определяется относительно его эквивалента, находящегося под управлением версий в связанном репозитории. Команды VCS в панели Projects доступны через пункт Version Control в контекстном меню панели (по правому щелчку).

Значки Version Control, как они отображаются в панели Projects

► Дополнительные сведения см. на странице Projects panel.

Панель Storage Manager

Панель Storage Manager предоставляет расширенное представление активного документа с точки зрения хранения файлов и дает доступ к функции локальной истории документа, а также к статусу/командам управления версиями.

Статус файла VCS в панели обозначается набором описаний и соответствующих значков, которые относятся к определенным состояниям файла, обнаруженным системой управления версиями. Состояние каждого файла, в общих чертах, определяется относительно его эквивалента, находящегося под управлением версий в связанном репозитории.

Панель Storage Manager

Команды VCS в панели Storage Manager доступны из контекстного меню по правому щелчку. Чтобы выполнить действие VCS для конкретного файла, щелкните правой кнопкой по его записи в панели и выберите нужную команду — например Commit, Update, Resolve conflict и т. п.

Историю ревизий выбранного файла и локальную историю документа можно увидеть в нижней части панели, либо общую временную шкалу событий, если переключиться в «classic view» — Switch to Classic View в параметрах по правому щелчку. Указанный номер ревизии будет увеличиваться с каждым коммитом VCS, при этом первая ревизия (Revision 1) соответствует созданию папок проекта VCS до добавления файлов.

► Дополнительные сведения см. на странице Storage Manager panel.

Статус Version Control

Для панелей Projects и Storage Manager текущий статус VCS каждого файла, находящегося под управлением версий, отображается рядом с его записью в панели.

Система управления версиями по сути отслеживает и сравнивает файлы в рабочей папке с их аналогами в репозитории проекта. Altium Designer запрашивает и обменивается информацией с системой управления версиями через свой VCS-интерфейс и соответствующим образом реагирует на сравнительные состояния файлов. На практике это проявляется в значках файлов в панелях Projects и Storage Manager, в виде набора предупреждений VCS, а также в соответствующих изменениях доступных команд управления файлами.

Значки и их значение описаны в разделе Version Control Status Icons на странице Managing Project Documents .

Многопользовательский доступ

В большинстве случаев инфраструктура системы контроля версий (VCS) в компании будет основана на центральных репозиториях SVN или Git, доступных по сети с использованием одного из доступных протоколов – svn, svn+ssh, https и т. д. Это обеспечивает доступ всем пользователям в сети (в соответствии с правами) и служит средством совместной разработки проекта из единого источника.

В свою очередь, возможности многопользовательского доступа позволяют разным участникам команды продолжать работу над проектом независимо, не ожидая, пока кто-то другой выполнит check-in файла, прежде чем они смогут с ним работать. Распределённая Git version control system развивает это преимущество ещё дальше, позволяя по мере работы выполнять commit файлов в локальный рабочий репозиторий, а затем «push» этих зафиксированных изменений обратно в центральный Git-репозиторий в любое более позднее время — и, таким образом, до этого момента подключение к сети не требуется.

Тем не менее, VCS, рассчитанная на командную работу, требует наличия инструментов и методов для разрешения неизбежной ситуации, когда два пользователя изменили один и тот же файл. Когда такие возможности доступны, создаётся основа для настоящей многопользовательской совместной разработки и связанных с ней преимуществ.

Для поддержки этого сценария Altium Designer включает возможности сравнения схем и PCB (или «diff»), доступные через панель Storage Manager panel.

Репозитории VCS

Лучший способ работать с известным набором исходных файлов — хранить проект разработки в контролируемой среде, например в репозитории системы контроля версий. Это важно, потому что единственный способ гарантировать, что выходные данные получены из правильных исходных файлов, — это:

1. Убедиться, что набор исходных файлов актуален.
2. Сделать их снимок (snapshot).
3. Сгенерировать выходные данные из этого снимка.

В Altium Designer такой репозиторий называется Design Repository. Принадлежащий команде разработчиков Design Repository содержит детализированное представление истории процесса проектирования и является основным инструментом совместной работы, используемым командой.

Design Repository становится центральным репозиторием, из которого несколько участников команды могут выполнять check-out и check-in данных, при этом сохраняется полная история ревизий всех изменений, внесённых в проект. Таким образом, разработка хранится как серия версий составляющих её проектных и исходных документов, формируя со временем последовательную картину замысла разработчика. Используя Design Repository под контролем версий, вы получаете встроенную гарантию, что ни одна ревизия проекта никогда не будет потеряна, что позволяет безопасно совместно работать над одним и тем же проектом членам команды, которые могут находиться в разных географических точках. Сама природа системы контроля версий обеспечивает аудит-трейл проекта. Полная ответственность достигается за счёт прозрачности: кто что изменил, в каком исходном документе и когда. Система может поддерживать несколько Design Repository под контролем версий, при этом связь с конкретным репозиторием устанавливается ссылкой контроля версий внутри папки проекта.

Перед использованием контроля версий файлы проекта должны быть распознаны и VCS, и Altium Designer как находящиеся под контролем версий. Этот процесс может отличаться для разных методов и приложений VCS, но по сути он включает создание и/или подключение к design repository и добавление файлов проекта разработки в этот репозиторий.

Design repositories основаны на структуре базы данных и внутренне хранят информацию в иерархии файлов и каталогов, называемой деревом файлов (file tree). Фактический репозиторий, к которому вы подключаетесь, может быть центральным SVN-репозиторием, рабочим Git-репозиторием (связанным с удалённым Git-репозиторием) или репозиторием, созданным вами в доступном месте — например на локальном ПК или в общей сетевой папке.

Обновление новых изменений в системе контроля версий

Когда проект добавлен под контроль версий, его локальная рабочая папка проекта теперь связана со своим соответствием в VCS-репозитории, что обозначается значком ссылки, связанным с записями папки проекта на панели Storage Manager. Чтобы подтвердить расположения связанной папки и репозитория, щёлкните правой кнопкой мыши по любой записи файла на панели и выберите опцию VCS Properties (недоступно при использовании Git). В следующем диалоге Properties отображаются пути связанных расположений и информация о последней ревизии VCS.

Файл, обозначенный значком ссылки, и соответствующая панель Properties , содержащая информацию о последней ревизии VCS

Диалог Properties предоставляет следующую информацию (только для просмотра; редактирование не допускается): 

• Path - путь к локальному документу в вашей рабочей папке).
• URL - URL расположения документа в VCS-репозитории.
• Repository Root - корень репозитория.
• Repository UUID - UUID репозитория.
• Revision - текущая ревизия документа в вашей локальной рабочей папке.
• Last Change Author - автор последнего изменения.
• Last Change Revision - ревизия последнего изменения
• Last Change Time - дата и время последнего изменения.
• Conflicted - находится ли документ в состоянии конфликта.

В результате зарегистрированной VCS-ссылки система контроля версий может отслеживать и обнаруживать любые различия между файлами в локальной папке проекта и их эквивалентами в папке VCS-репозитория. Когда различие обнаружено (например, когда файл проекта был отредактирован и сохранён в Altium Designer), система контроля версий изменит статус локального файла на Modified (), а Altium Designer предложит соответствующий набор команд VCS в контекстном меню (по правому клику) на панелях.

Фиксация изменений (Commit)

После того как файл документа проекта был отредактирован и сохранён в Altium Designer, он помечается как Modified и отображается соответствующим образом () как на панели Projects, так и на панели Storage Manager. Чтобы зафиксировать эти изменения как новую ревизию в VCS, щёлкните правой кнопкой мыши по записи файла на панели и выберите команду Commit в контекстном меню или выберите команду Project » History & Version Control » Commit в главном меню.

При фиксации изменения файла откроется диалог Edit Comment dialog. Используйте этот диалог, чтобы добавить комментарий с указанием причины commit — это помогает другим понять, какие изменения были внесены. Если вы добавляли комментарии ранее, вы можете быстро выбрать один из них.

Команда Commit

Также можно использовать команду Commit Whole Project, которая выполнит commit всех изменённых файлов в проекте. При фиксации всего проекта откроется диалог Commit to Version Control.

Диалог Commit to Version Control

• When using Subversion (SVN):Процесс commit копирует обновлённый файл из локальной папки в репозиторий, увеличивая номер ревизии записи VCS и возвращая статус файла обратно в No Modification ().
• When using Git:Процесс commit обновляет локальный рабочий репозиторий VCS, одновременно увеличивая номер ревизии записи и устанавливая статус файла в Ahead of Server (). Вы можете продолжать редактировать, сохранять и выполнять commit файлов в рабочем репозитории или утвердить новые изменения, используя команду Push для обновления удалённого Git-репозитория — после этого статус файла вернётся к No Modification ().

Откройте панель Storage Manager, чтобы увидеть последовательность действий в разделе VCS Revisions, которая будет включать создание новой ревизии VCS (с увеличенным номером ревизии) для этого файла — в данном случае ревизия 3 и добавленный к ней комментарий. Значок указывает последнюю и текущую ревизию выбранного файла или, в терминах контроля версий, ревизию Head.

Раздел VCS Revisions панели Storage Manager

Для совмещённого просмотра записей ревизий и событий истории переключитесь на единый вид Timeline, выбрав Switch to Combined View в контекстном меню (правый клик).

Check out из системы контроля версий

Как описано выше, локальный проект, добавленный под контроль версий, можно редактировать в Altium Designer из локальной папки проекта, а изменения затем обновляются в репозитории VCS. Локальная папка и папка репозитория связаны и в конечном итоге синхронизируются системой VCS.

Другой пользователь, у которого не будет доступа к проекту из его исходной папки (локальной на вашем ПК), может использовать процесс Clone (Git) или Check Out (SVN), чтобы получить собственную копию файлов из репозитория VCS, в котором размещён проект. Всем пользователям, которые хотят совместно работать над проектом, необходимо подключаться к этому общему репозиторию проекта, который обычно настраивается как доступный через локальную сеть или с сервера.

Выбранная папка проекта в репозитории и входящие в неё файлы будут извлечены (checked out) в указанную локальную папку и открыты в Altium Designer. Обратите внимание: локальная папка — это та, что определена как папка checkout для выбранного репозитория, а извлечённый проект затем связывается со своей копией в репозитории VCS. Связь VCS указывает системе контроля версий отслеживать и обнаруживать любые различия между файлами в локальной папке checkout и их эквивалентами в папке репозитория VCS.

Выполните commit изменений после завершения редактирования файлов — это синхронизирует файлы в репозитории проекта так, чтобы они соответствовали файлам в папке checkout, и создаст новую ревизию VCS.

Checkout и Open Project: в чём разница

Когда проект local добавлен под контроль версий, на самом деле есть два способа редактировать его и обновлять в VCS:

• Открыть локальный проект (File » Open Project) в Altium Designer, а затем выполнять commit сохранённых изменений в репозиторий VCS. В этом случае локальная папка проекта и соответствующая ей папка в репозитории связаны системой VCS.

  

• Выполнить check out проекта (File » Check Out) из репозитория VCS, а затем выполнять commit сохранённых изменений, сделанных в Altium Designer, обратно в репозиторий. В этом случае проект в указанной папке checkout и соответствующая ему папка в репозитории связаны системой VCS.

  

Локальный проект является источником (origin) VCS-проекта, который предоставляется другим пользователям. В зависимости от того, как вы хотите работать, эту локальную исходную версию можно удалить или заблокировать как архивный исходник проекта, а затем использовать подход Check Out для дальнейших правок. Либо вы можете продолжать открывать и работать с файлами проекта из локальной «исходной» папки (Open Project).

Лучше придерживаться одного метода (рекомендуется check out), поскольку эти два варианта работают с рабочей папкой в разных местах — в локальной исходной папке проекта или в указанной папке VCS checkout. Если же использовать оба метода, на локальном ПК будет несколько активных копий одного и того же проекта. Однако если после каждого редактирования добросовестно выполнять Commit в централизованный репозиторий VCS, репозиторий всегда будет содержать последнюю ревизию проекта, как и задумано.

Также обратите внимание: после того как проект был первоначально извлечён (checked out) из репозитория VCS, он появляется локально и может быть повторно открыт напрямую из папки checkout (File » Open Project). В этом случае снова есть выбор — выполнять check out проекта из VCS или открывать локальную версию, однако локальная копия всегда только одна. С практической точки зрения VCS эти два метода очень похожи, но в некоторых ситуациях ведут себя по-разному — например, когда локальный файл отсутствует: процесс check out восстановит его, а команда Open Project удалит его из Project.

Ревизии системы контроля версий

В процессе работы с проектными документами в Altium Designer, находящимися под контролем версий, файлы проекта, полученные из центрального (общего) репозитория VCS, будут представлять последнюю ревизию этих файлов. Когда локальные правки завершены и зафиксированы (или, в случае Git, отправлены push) обратно в общий репозиторий VCS, эти версии файлов становятся последними ревизиями.

Таким образом, обычная последовательность check out, edit, save и commit (и Push для Git) постепенно добавляет новые ревизии файлов в центральный VCS по мере развития проекта. Однако при совместной разработке проекта несколькими инженерами новые ревизии могут быть зафиксированы в центральном (общем) репозитории в любой момент любым участником.

Устаревшая ревизия

Взаимодействие нескольких разработчиков и центрального репозитория может проявляться по-разному; один из вариантов — локально открытый проект больше не является последней ревизией: проект, извлечённый из репозитория или открытый из локальной рабочей папки, имеет статус Out of date () в панели Projects.

Файл с меткой Out of fate

В этом случае другой пользователь отредактировал и выполнил commit того же проекта в репозиторий после того, как он в последний раз редактировался локально. Например, локальный пользователь Barry работает над проектом и выполнил commit, скажем, Revision 14, но другой пользователь Harold после этого выполнил commit Revision 15, как показано в панели Storage Manager ниже. Поскольку VCS обнаруживает различие между файлом в локальной рабочей папке и его копией в репозитории (которая в данном случае новее), система считает самую новую ревизию local (обозначенную значком ) устаревшей.

Различные состояния ревизий в Storage Manager

Эта ситуация исправляется обновлением локальных файлов до соответствия файлам в центральном репозитории VCS с помощью команды Update из контекстного меню (правый клик) панели Projects или Storage Manager. После этого две версии файла синхронизируются, а локальная версия (для пользователя Barry) обновляется до последней ревизии — в данном примере Revision 15. Обратите внимание: если выполнить Save файла, когда он обозначен как Out of date, будет создана ситуация VCS Conflict, при которой VCS обнаружит, что в рабочей папке была обновлена более старая ревизия файла.

Центральный репозиторий и локальная ревизия в Storage Manager

Вы также можете выбрать команду Update Whole Project, чтобы открыть диалог Update from Version Control и выбрать файлы для извлечения (check out) из общего репозитория. В диалоге отображаются все документы проекта, которые устарели или содержат конфликты. Вы можете выбрать конкретные документы для обновления или обновить все сразу. Выбранные документы обновляются из репозитория, а все устаревшие документы по умолчанию уже выделены. Все выбранные документы будут обновлены до последней версии в репозитории.

Диалог Update from Version Control

Столбец Path отображает каталог файла. Столбец Status отображает текущий статус файла. Если статус файла отображается как Conflict, нажатие OK для обновления файлов вызовет диалог подтверждения. Нажмите OK, чтобы обновить до последней версии в репозитории, или Cancel, чтобы выйти и сохранить изменения в версии, которая сейчас находится в репозитории.

Конфликт ревизий

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

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

Пример конфликта ревизий

С точки зрения VCS, которая сравнивает файлы в рабочей папке с файлами в репозитории, Conflict представляет собой состояние, когда устаревшая ревизия файла в рабочей папке была отредактирована и сохранена.

Ревизии Git VCS в панели Storage Manager

Существует несколько команд, доступных из контекстного меню (правый клик) панели Projects, из Project » History & Version Control главного меню и из панели Storage Manager, которые можно использовать, когда файл имеет статус Conflict:

• Commit – этот вариант вызовет ошибку Subversion, поскольку фиксация локально отредактированной ревизии (например, Revision 15) перезаписала бы более новую ревизию (Revision 16), уже зафиксированную другим пользователем.
• Update – этот вариант обновит локальную ревизию файла до последней версии из центрального репозитория (Revision 16), при этом будут потеряны любые локальные изменения, которые вы внесли в Revision 15.

• Resolve Conflict – этот вариант отменит изменения, зафиксированные в репозитории с момента вашего последнего обновления. После запуска команды появится диалог подтверждения — нажмите Yes для продолжения. Файл проекта в вашей рабочей папке будет обновлён до последней ревизии, внесённой в репозиторий другим пользователем, но редактор сохранит изменения, которые вы сделали в предыдущей ревизии. Таким образом, локальный файл получает состояние Modified, что позволяет зафиксировать эти изменения как новую ревизию в репозитории — с помощью команды Commit или команды Commit Whole Project . После того как вы зафиксируете файл проекта, другой пользователь увидит файл(ы) как Out of date, поскольку вы создали более новую ревизию в репозитории.

  Этот вариант рекомендуется только когда файл text находится в конфликте, поскольку система Subversion попытается выполнить слияние (Merge) различий в локальный файл. Этот процесс потенциально может повредить другие типы файлов, например проектные документы, поэтому конфликт лучше всего разрешать обновлением до последней исходной ревизии или откатом локальных изменений (Revert).

  При использовании Git команда Resolve Conflict переопределит состояние конфликта, зафиксировав файл в локальной папке репозитория. Когда затем файл будет отправлен (Push) в удалённый репозиторий, файл другого разработчика будет помечен как Out of Date и должен быть обновлён. Однако, как и при использовании Subversion, самый безопасный путь — Update конфликтующий файл до последней исходной ревизии (в терминах Git — Pull) или Revert локальные изменения.
• Revert – этот вариант приведёт к потере (отмене) локальных изменений, вернув локальный файл к его базовой ревизии — здесь, Revision 15. Конфликт ревизий таким образом будет устранён, но файл затем будет помечен как Out of date, поскольку в репозитории существует более новая ревизия (Revision 16).

Сравнение ревизий

Ценным преимуществом работы с Version Control является возможность сравнивать исторические ревизии проектных файлов, что обеспечивается встроенным в Altium Designer компаратором различий (Difference Comparator) и доступно из панели Storage Manager. При использовании совместно с панелью Differences можно выполнить логическое или графическое сравнение ревизий VCS, интерактивно исследуя затронутые объекты. Можно сравнивать ревизии как схем, так и PCB.

Чтобы инициировать сравнение двух ревизий, выберите обе записи (стандартным Ctrl+click способом) в списке панели Storage Manager VCS Revisions, затем выберите команду Compare в контекстном меню панели (правый клик).

Команда Compare в панели Storage Manager

Обе ревизии файла будут открыты в режиме разделённого экрана, где их можно визуально сравнить. Отображаемые различия определяются параметрами, выбранными для типов физического сравнения на вкладке Comparator tab диалога Options for Project — Project » Project Options.

Ключ к поиску и просмотру различий сравнения — панель Differences, которая предоставляет выбираемый список логических или графических различий между документами. Элементы списка панели для каждой ревизии документа взаимодействуют с редактором, позволяя при выборе графически подсветить обнаруженное различие (например, перемещённый объект).

Поиск и просмотр различий сравнения выполняется в панели Differences

Функция Compare также применима к ревизиям PCB-документов, наряду с ревизиями схем и текстовых документов.

• Для документов схем или PCB (проектных или библиотечных) выполняется графическое сравнение, а обнаруженные различия перечисляются в панели Differences. Когда две версии документа открыты рядом в окне редактора, вы можете просматривать различия графически. Щелчок по папке верхнего уровня для обнаруженного различия подсветит это различие одновременно в обоих документах.
• Для текстовых ASCII-документов появится диалог CompareForm , показывающий графический «diff» двух версий документа. Выбранные документы отображаются рядом. Диалог предназначен только для сравнения — изменения в загруженном документе вносить нельзя. Благодаря цветовой маркировке диалог подсвечивает различные отличия между двумя версиями документа: добавленные строки (розовый), изменённые строки (зелёный) и удалённые строки (синий). Сводка изменений и легенда цветов представлены в нижней левой части диалога.

Функциональность Compare

Команда Compare может применяться к любой паре ревизий, включая сравнение текущей локальной ревизии (в рабочей папке) и более новой ревизии в репозитории. В этой ситуации последняя локальная ревизия обозначается в панели Storage Manager как Out of date (), но при этом её всё равно можно сравнить с более новой ревизией, добавленной в репозиторий другим пользователем.

Локальная ревизия обозначена в панели Storage Manager как Out of date

Такой подход позволяет графически предварительно просмотреть изменения, которые будут применены при обновлении до новой ревизии. В примере на изображении выше текущая локальная ревизия (обозначенная значком ) — Revision 19, но другой пользователь зафиксировал новую ревизию в репозитории (Revision 22). Запуск визуального сравнения между Revision 19 и Revision 22 позволяет принять обоснованное решение о принятии новых изменений из репозитория и, как следствие, о том, примените ли вы команду Update или переопределите её, вызвав состояние Conflict — throu gh повторное сохранение локального файла и разрешение конфликта в пользу вашей локальной версии.

Терминология Version Control

Ссылки

• Сайт SVN: http://subversion.apache.org/
• Онлайн-руководство SVN: http://svnbook.red-bean.com/
• Домашняя страница проекта SharpSVN: https://sharpsvn.open.collab.net
• Сайт Git: https://git-scm.com/
• Онлайн-документация Git: https://git-scm.com/doc
• Клиенты Tortoise: http://tortoisesvn.net и https://tortoisegit.org/
• Руководство «Source Control How-to», автор Eric Sink: http://www.ericsink.com/scm/source_control.html