Система контроля версий Системы контроля версий Version

Система контроля версий

Системы контроля версий (Version Control System, VCS) При разработке крупных проектов мы можем столкнуться с рядом трудностей, например: • • • изменяем код, а потом хотим «откатить» изменения. каждую версию можно сохранять в отдельную папку, но со временем станет сложно управляться с большим количеством файлов. если над программой работает сразу несколько человек, было бы неплохо автоматизировать процесс объединения сделанных ими изменений.

Система контроля версий (VCS) умеет: - восстанавливать старые версии; - синхронизировать между собой самые новые версии. Есть много разных VCS: - Perforce, Microsoft Visual Sourcesafe (платные), - CVS, Subversion (бесплатные). Мы будем говорить о Subversion (система управления версиями), известной также как svn (по названию программы-клиента для командной строки, входящей в состав программного пакета). Это клиент-серверная система, состоящая из: - сервера (к примеру, svnserve), на котором есть репозиторий (repository) - база данных, - клиентских машин, на которых есть рабочие копии (working copies).

Хранилище (репозиторий) • • Subversion является централизованной системой для совместного использования информации. Хранилище –центр хранения данных содержит информацию в форме дерева файлов. Любое количество клиентов подключается к хранилищу и читает или записывает эти файлы. Записывая данные, клиент делает информацию доступной для остальных; читая данные, клиент получает информацию от других. Типичная клиент/серверная система

• Хранилище является разновидностью файл-сервера, однако не совсем обычного. • Хранилище Subversion запоминает каждое внесенное изменение: - любое изменение любого файла, - изменения в самом дереве каталогов, такие как добавление, удаление и реорганизация файлов и каталогов. • При чтении данных из хранилища клиент обычно видит только последнюю версию дерева файлов. • Клиент также имеет возможность просмотреть предыдущие состояния файловой системы. • Вопросы типа «Что содержал этот каталог в прошлую среду? » , «Кто был последним, изменявшим этот файл, и какие вносились изменения? » являются основополагающими для любой системы управления версиями — системы, разработанной для записи и отслеживания изменений информации во времени.

Назначение SVN – открытая система управлениями версиями файлов и каталогов проектов с центральным хранилищем (репозиторием) и сетевым доступом. SVN предназначена для: • хранения всех версий исходных файлов проекта; • обеспечения возможности одновременной работы с одними и теми же файлами проекта для множества участников; • сопровождения нескольких версий проекта одновременно (работа с ветвями).

История Разработка Subversion была начата в 2000 г. по инициативе и при финансовой поддержке Collab. Net Inc. Цель проекта - заменить собой распространенную на тот момент систему Concurrent Versions System (CVS), которая ныне считается устаревшей. Subversion реализует все основные функции CVS и свободна от ряда недостатков последней.

• • • Основные события истории развития Subversion: 31 августа 2001 года команда разработчиков перешла с CVS на Subversion для управления собственным исходным кодом. Subversion стала «самодостаточной» . 23 февраля 2004 года вышел релиз 1. 0. 0. К этому времени Subversion уже использовалась примерно на 1400 серверах с открытым доступом. 29 сентября 2004 года появился релиз 1. 1. 0. Среди основных нововведений - новый формат хранилища файлов. 21 мая 2005 года вышел релиз 1. 2. 0, в котором добавлена возможность блокировки файлов. 30 декабря 2005 года вышел релиз 1. 3. 0. Основными изменениями являются возможность устанавливать права доступа к директориям при использовании svnserve. 10 сентября 2006 года вышел релиз 1. 4. 0. Включены функции самовосстановления. 19 июня 2008 года вышел релиз 1. 5. 0. Введена базовая поддержка отслеживания слияний (merge tracking). 20 марта 2009 года вышел релиз 1. 6. 0. Улучшения поддержки svn: externals, обнаружение «конфликтов деревьев» (tree conflict), улучшение эффективности хранения данных в репозитории. В феврале 2010 года проект Subversion был официально переведён под управление Apache Software Foundation (ASF). 11 октября 2011 года состоялся релиз 1. 7. Основные улучшения: теперь только одна папка. svn в корне рабочей копии; ускорена работа по HTTP; добавлена утилита svnrdump; новая команда svn patch.

• В настоящее время Subversion используется многими сообществами разработчиков открытого программного обеспечения. • В их числе такие известные проекты, как Apache, GCC, Free Pascal, Python, Ruby, Mono, Free. BSD, Haiku, AROS, Media. Wiki. • Subversion также широко используется в закрытых проектах и корпоративной сфере. • В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)» . • В качестве официальной документации позиционируется книга издательства O'Reilly Media, (http: //svnbook. redbean. com/) дописываемая авторами по мере выхода новых версий SVN. • Англоязычные версии книги описывают сейчас версии 1. 6 и 1. 5, • На русском языке имеются книги, описывающие версии до 1. 4 включительно.

Возможности SVN • Хранение полной истории изменений отслеживаемых объектов (файлов, каталогов, символьных ссылок) в централизованном хранилище (репозитории), в том числе при изменении атрибутов ( «метаданных» ), перемещении, переименовании и удалении • Копирование объектов с разветвлением истории - при копировании в хранилище появляются два отдельных объекта с общей историей • Поддержка переноса изменений между копиями объектов, в том числе полного слияния копий • Поддержка ветвления: – создание ветвей (копированием директорий) и работа с ними – слияние ветвей (переносом изменений) • Поддержка меток (копированием директорий) • Поддержка конкурентной (в том числе одновременной, с изоляцией транзакций) многопользовательской работы с хранилищем и, в большинстве случаев, автоматическим слиянием изменений различных разработчиков (в рабочей копии)

Возможности SVN (продолжение) • Фиксации изменений в хранилище (в том числе многообъектные) организуются в виде атомарных транзакций • Сетевой обмен между сервером и клиентом предусматривает передачу только различий между рабочей копией и хранилищем • Обеспечивается одинаково эффективная работа как с текстовыми, так и с двоичными файлами • Различные варианты доступа к хранилищу, в том числе: – непосредственный доступ на локальной файловой системе; – по собственному сетевому протоколу; – через веб-сервер по протоколу Web. DAV/Delta. V. • Вывод клиента командной строки одинаково удобен и для чтения, и для разбора программами • Два возможных внутренних формата репозитория: база данных или набор обычных файлов • Библиотеки для языков PHP, Python, Perl, Java позволяют встроить функциональность клиента Subversion в программы, написанные на этих языках • Многоуровневая архитектура библиотек, изначально рассчитанная на клиент-серверную модель

А теперь для «чайников» • • • Контроль изменений каталогов. SVN использует «виртуальную» файловую систему с возможностями управления версиями, которая способна отслеживать изменения во времени целых структур каталогов Настоящая история версий. SVN делает возможным добавление, удаление, копирование и переименование как файлов, так и каталогов. При этом каждый вновь добавленный файл начинает жизнь с чистого листа, сохраняя собственную историю изменений Атомарная фиксация изменений. Каждый набор изменений либо попадает в хранилище целиком, либо не попадает туда вовсе. Т. е. если при фиксации изменений проекта произошла ошибка при обработке файла, то изменения всего проекта не будут зафиксированы Метаданные с версиями. Каждый файл и каталог имеет собственный набор свойств, представленных в виде названия и значения. Вы можете создавать и сохранять любые необходимые пары названий свойств и их значений. Свойства файлов точно так же находятся под управлением версиями, как их содержимое Единый способ работы с данными. SVN обнаруживает различия между файлами с помощью специального бинарного алгоритма, который одинаково работает как с текстовыми, так и с бинарными файлами. Файлы записываются в хранилище в сжатом виде независимо от их типа, а различия между отдельными версиями могут передаваться по сети в обоих направлениях Эффективные ветки и метки. SVN создаёт ветки и метки путём простого копирования проекта, используя механизм, похожий на жёсткие ссылки в файловых системах. Благодаря этому, операции по созданию веток и меток занимают немного времени

Архитектура SVN

Типы репозиториев Subversion предлагает два варианта организации репозиториев: - базы данных на основе Berkeley DB; - обычные файлы специального формата (доступ к данным организуется с помощью собственных библиотек, без использования сторонних баз данных). Разработчики Subversion часто называют хранилище «файловой системой» , поэтому второй тип получил название FSFS, то есть версионированная файловая система (File System) поверх обычной файловой системы. Оба типа репозиториев обеспечивают достаточную надёжность при правильной организации. Berkeley DB использует блокировки файлов, поэтому её нельзя использовать на некоторых сетевых файловых системах, не поддерживающих блокировок. Каждый из них обладает своими преимуществами и недостатками: - FSFS легче правильно настроить, она требует меньшего внимания от администратора. до релиза 1. 4 хранилища, использующие Berkeley DB могли при определённых условиях оказаться в так называемом заклиненном (wedged) состоянии; требовалось вмешательство администратора для восстановления его работоспособности. Начиная с релиза 1. 2 для новых хранилищ по умолчанию используется FSFS.

Модель работы • Subversion — централизованная система, то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере. • Работа в Subversion мало отличается от работы в других централизованных системах управления версиями. • Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и фиксируют эти изменения в хранилище. • Несколько клиентов могут одновременно обращаться к хранилищу.

В связи с тем, что разработчики работают только с локальными копиями, могут возникать трудности, когда два и более человек изменяют один и тот же файл. В SVN есть две модели, позволяющие избегать этой проблемы: • • Блокирование - изменение - разблокирование. Согласно этой модели, когда кто-либо начинает работу с файлом, этот файл блокируется, и все остальные пользователи теряют возможность его редактирования. Очевидным недостатком такой модели является то, что файлы могут оказаться надолго заблокированными, что приводит к простоям в разработке проекта. Копирование - изменение - слияние. В данной модели каждый разработчик свободно редактирует свою локальную копию файлов, после чего выполняется слияние изменений. Недостаток этой модели в том, что может возникать необходимость разрешения конфликтов между изменениями файла. Вторая модель является основной. В то же время для некоторых типов файлов (например, изображения) целесообразно использовать первую модель.

Проблема разделения файлов Всем системам управления версиями приходится решать одну и ту же основную проблему: - как предоставить пользователям возможность совместного использования информации, - пользователи могут случайно перезаписать в хранилище изменения, сделанные другом. • • • Допустим, у нас есть два соразработчика — Гарри и Салли. Каждый из них решил одновременно отредактировать один и тот же файл из хранилища. Если первым свои изменения в хранилище сохранит Гарри, то возможно, что (несколькими минутами позже) Салли может непреднамеренно перезаписать их своей новой версией файла. Несмотря на то, что версия файла Гарри не будет полностью потеряна (так как система помнит каждое изменение), внесенные Гарри изменения не будут отражены в новой версии файла Салли, потому что, начиная, она не видела изменения Гарри. Работа Гарри фактически потеряна — или, по крайней мере, отсутствует в последней версии файла — по случайности. Как раз этой ситуации мы и хотим избежать!

Проблема потери изменений (иллюстрация)

Модель Блокирование-Изменение-Разблокирование Эта модель запрещает одновременное редактирование файла несколькими пользователями. Эксклюзивность доступа гарантируется блокировками. Перед началом редактирования Гарри должен «заблокировать» файл. Если Гарри заблокирует файл, Салли уже не сможет его разблокировать и внести свои изменения. Ей остается только читать файл и ждать, пока Гарри закончит свои изменения и снимет блокировку. Лишь после того, как Гарри разблокирует файл, Салли сможет получить его, заблокировать и начать редактирование.

Проблемой модели блокирование-изменение-разблокирование является то, что она немного ограниченная и часто доставляет неудобства пользователям: • • • Блокирование может вызвать проблемы администрирования. Иногда Гарри может заблокировать файл, а затем забыть об этом. Между тем, ожидая редактирования файла, у Салли будут связаны руки. А Гарри тем временем уехал в отпуск. Теперь Салли, для снятия блокировки Гарри, нужно обращаться к администратору. Ситуация заканчивается не нужной задержкой и потерянным временем. Блокирование может вызвать излишнюю пошаговость. Вполне вероятна ситуация, когда Гарри редактирует начало текстового файла, а Салли нужно отредактировать концовку этого же файла? Эти изменения совсем не перекрываются. Они могли бы легко редактировать файл одновременно, и при условии корректного слияния изменений это не вызвало бы никаких особенных проблем. Нет никакой необходимости блокировать файл в такой ситуации. Блокирование может вызвать ложное чувство безопасности. Предположим, что Гарри блокирует и редактирует файл А, в то время как Салли одновременно блокирует и редактирует файл В. Но допустим, что А и В зависят друг от друга и сделанные в каждом изменения семантически не совместимы. Неожиданно А и В больше не работают вместе. Блокирующая система бессильна в предотвращении проблемы — вместо этого она обеспечила ложное чувство безопасности. Для Гарри и Салли просто вообразить, что, блокируя файлы каждый начинает безопасную изолированную задачу и не беспокоиться об обсуждении их несовместимых изменений заранее. Зачастую, блокирование подменяет настоящее общение.

Модель Копирование-Изменение-Слияние • В этой модели каждый пользовательский клиент связывается с хранилищем проекта и создает персональную рабочую копию - локальное отражение файлов и каталогов хранилища. • После этого пользователи работают одновременно и независимо друг от друга, изменяя свои личные копии. • В конце концов, личные копии сливаются в новую, итоговую версию (система помогает, но за корректное выполнение отвечает человек). • В качестве примера предположим, что Гарри и Салли создали рабочие копии одного и того же проекта, скопировав их из хранилища. Они работают одновременно и в своих рабочих копиях вносят изменения в один и тот же файл А. • Первой свои изменения в хранилище сохраняет Салли. • Когда позже Гарри попытается сохранить свои изменения, хранилище проинформирует его о том, что его файл А устарел. • Поэтому Гарри просит свой клиент слить любые изменения из хранилища в его рабочую копию файла А. • По счастливому совпадению, изменения Салли не перекрываются с его собственными; после объединения обоих наборов изменений он сохраняет свою рабочую копию обратно в хранилище.

Модель копирование-изменение-слияние

Конфликт • А что будет, если изменения Салли перекрывают изменения Гарри? • Эта ситуация называется конфликтом и, как правило, это не является большой проблемой. • Когда Гарри просит свой клиент слить последние изменения из хранилища в рабочую копию, его копия файла А помечается некоторым образом как находящаяся в состоянии конфликта: - у Гарри будет возможность видеть оба набора конфликтующих изменений и вручную сделать между ними выбор. • Помните, что ПО не может автоматически разрешать конфликты; только человек способен к пониманию и выполнению осмысленного выбора. Разрешив вручную перекрывающиеся изменения - возможно, после обсуждения с Салли - он может безопасно сохранить объединенный файл обратно в хранилище.

Вывод • Модель копирование-изменение-слияние может выглядеть немного хаотично, однако, на практике она отлично работает. • Пользователи могут работать параллельно, не тратя время на ожидание друга. • При работе над одними и теми же файлами оказывается, что большинство параллельно вносимых изменений совсем не перекрываются; конфликты бывают редко. • И время, которое было потрачено на разрешение конфликтов, как правило, значительно меньше времени, отнимаемого блокирующей системой.

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

Список основных терминов • • Репозиторий (repository) — централизованное хранилище исходных кодов, рабочих материалов и документации. Любое количество клиентов подключается к хранилищу и читает или записывает эти файлы Рабочая копия/working copy (WC) — обычное дерево каталогов на компьютере, содержащие набор файлов для работы над проектом. Изменения в рабочей копии не доступны для других пользователей репозитория, до тех пор пока они не будут зафиксированы. Trunk — основное направление разработки Branch (''Ветка'') - направление разработки, которое существует независимо от другого направления, но имеет с ним общую историю. Ветка всегда берет начало как копия чего-либо и движется от этой точки, создавая свою собственную историю Tag (''Метка'') — выделенная явно, через создание отдельной папки версия файлов проекта в определенный момент времени. Revision — номер ревизии репозитория, в пределах репозитория номер ревизии уникальная величина Checkout – команда, которая выполняет начальное получение проекта из репозитория в WC. Commit – команда, которая выполняет фиксацию изменений файлов проекта в WC в Репозиторий.

Список основных терминов (продолжение) • Update – команда, которая выполняет обновление файлов проекта в WC из репозитория • Revert – команда, которая выполняет отмену любых изменений в файлах проекта в WC на основе номера ревизии репозитория. • Merge – команда, которая выполняет слияние файлов из разных веток проекта и помещает результат слияния в WC. • Conflict – ситуация, возникающая при фиксации изменений, когда одни и те же файлы изменяли несколько разработчиков. • Resolve – набор правил по разрешению возникающих конфликтов. • Import – команда, для быстрого копирования дерева файлов в Репозиторий. • Export – команда, для экспорта проекта, отличается от checkout тем, что не создает в папках проекта служебную информацию. • Switch – команда, которая выполняет переключение WC на другую ветку разработки. • Create, Add, Delete, Copy, Move, Rename – команды для управления файлами и папками в репозитории или WC.

Структура хранилища (репозитория) Три основных понятия: • Trunk — основное направление разработки. • Branch ( «Ветка» ) — направление разработки, которое существует независимо от другого направления, но имеет с ним общую историю. • Tag ( «Метка» ) — выделенная явно через создание отдельной папки версия файлов проекта в определенный момент времени.

Основные концепции

Файловая система

• С точки зрения пользователя хранилище Subversion представляет собой «двумерную» файловую систему. • Объекты в хранилище (файлы и директории) идентифицируются двумя «координатами» : - именем ревизии, - номером ревизии. • Хранилище представляет собой массив мгновенных снимков (ревизий) дерева файлов и директорий, индексируемый номером ревизии. Каждый такой снимок - обычная (одномерная) файловая система. • При необходимости указания на конкретную ревизию объекта используется запись вида: - имя@ревизия, - например, /main. c@29 - файл /main. c в ревизии 29. • Такое указание ревизии, используемое для уточнения имени, называется стержневая ревизия ( peg revision).

Имена файлов • Имя объекта файловой системы в Subversion образуется по тем же правилам, что и в UNIX-подобных операционных системах: – существует только одна корневая директория, – элементы пути разделяются косой чертой ( «/» ). • Объектами файловой системы являются файлы и директории (а также символические ссылки, которые эмулируются из обычных файлов путём установки атрибута svn: special). Номера ревизий • Номер ревизии в Subversion — это натуральное число (или 0 для самой первой ревизии), адресующее номер состояния хранилища в процессе изменения содержащихся в нём данных. Каждая успешная фиксация изменений порождает ровно одну новую ревизию в хранилище, то есть N-я ревизия — это состояние хранилища после N-й фиксации. • В Subversion ревизия характеризует состояние не отдельного файла, а всего хранилища в целом. Например, ревизия 32 (обведено пунктиром на рисунке) — это состояние трёх файлов и двух директорий, существовавших в хранилище на тот момент. • Номер ревизии является аналогом времени в том смысле, что меньшие номера ревизий соответствуют более ранним состояниям хранилища, а бо льшие - поздним. В нулевой ревизии хранилище содержит только пустую корневую директорию.

Операции над файловой системой Над объектами файловой системы в хранилище Subversion могут быть произведены следующие операции (в скобках указано краткое именование операции в обозначениях команды svn status): • Добавление - add (A). Добавление объекта в файловую систему. Добавленный объект не имеет истории ревизий. – файл /main. c был добавлен в ревизии 27. • Модификация - modify (M). Модификация объекта, например, изменение содержимого файла или изменение свойств файла или директории. – файл /main. c был модифицирован в ревизии 28. • Удаление - delete (D). Удаление файла из головной и последующих ревизий. При этом файл остаётся в предыдущих ревизиях. – файл /main. c был удалён в ревизии 30.

Операции над файловой системой • Добавление с историей – added with history (A+). Представляет собой копирование объекта внутри файловой системы хранилища, то есть объект имя_источника@ревизия_источника копируется в имя_копии@HEAD. • Скопированный объект наследует от источника историю ревизий до момента копирования (наследование истории показано на рисунке пунктирными связями) - в ревизии 29 директория /tags/R 1 была скопирована с директории /trunk@27; - в ревизии 31 файл /main. c был скопирован с /main. c@29, то есть с более ранней ревизии самого себя, таким образом, произведено восстановление ранее удалённого (в ревизии 30) файла с сохранением истории ревизий.

Операции над файловой системой • Замена (R+). Имеет место в случае, когда в одной ревизии произведено и удаление объекта (D), и добавление с историей (A+) объекта с тем же самым именем. Хотя имя при операции замены остаётся неизменным, Subversion рассматривает объект до и после замены как два различных объекта с различными историями ревизий (история старого заканчивается в точке замены, история нового наследуется от источника копирования и продолжается далее). Пример на рисунке: • в ревизии 30 файл /file. txt был заменён: старый файл /file. txt удалён, а новый файл с тем же именем скопирован с файла /bar. txt@29

Операции над файловой системой • Замена -replace (R+). Имеет место в случае, когда в одной ревизии произведено и удаление объекта (D), и добавление с историей (A+) объекта с тем же самым именем. • Хотя имя при операции замены остаётся неизменным, Subversion рассматривает объект до и после замены как два различных объекта с различными историями ревизий (история старого заканчивается в точке замены, история нового наследуется от источника копирования и продолжается далее). - в ревизии 30 файл /file. txt был заменён: - старый файл /file. txt удалён, - новый файл с тем же именем скопирован с файла /bar. txt@29.

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

Рабочая копия • Рабочая копия - это созданная клиентской программой Subversion локальная копия части данных из хранилища, содержащая также некоторую служебную информацию: - скрытые директории с именем. svn • Служебная информация необходима для правильного функционирования рабочей копии; что-либо менять в служебных данных нельзя. • Минимальной единицей данных, которую можно получить из хранилища как рабочую копию, является директория. • Можно также извлечь директорию без поддиректорий, а потом докачивать их по мере необходимости.

• Рабочая копия в Subversion всегда соответствует ровно одной директории хранилища. • Извлечь из хранилища отдельный файл как рабочую копию невозможно. • Рабочая копия является самодостаточной в том смысле, что Subversion не хранит каких-либо данных, относящихся к рабочей копии, вне её. • Имея одну рабочую копию, можно сделать ещё несколько копий простым копированием без затрат сетевого трафика. • Создание рабочей копии является первым и необходимым этапом для фиксации локальных изменений. • Зафиксировать в хранилище можно только изменения, сделанные в рабочей копии.

• Ваша рабочая копия - это ваше личное рабочее пространство. • Subversion как не смешивает с вашими изменения, вносимые другими, так и не делает доступными для других изменения, сделанные вами, пока вы сами не прикажете сделать это. • После того, как вы внесли изменения в файлы вашей рабочей копии и убедились в том, что они корректно работают, Subversion предлагает вам команды «публикации» (записи в хранилище) ваших изменений, в результате чего они станут доступными для всех участников проекта. • Если другие участники проекта опубликовали свои изменения, Subversion предлагает вам команды для объединения (путем чтения информации из хранилища) этих изменений с вашей рабочей копией.

Предположим, что есть хранилище, содержащее два программных проекта: paint и calc. Каждый проект располагается в своем собственном каталоге.

Для того, чтобы создать рабочую копию, нужно получить какой-либо из подкаталогов хранилища. Например, если вы получите /calc, у вас будет рабочая копия наподобие этой: $ svn checkout http: //svn. example. com/repos/calc A calc/Makefile A calc/integer. c A calc/button. c Checked out revision 56. $ ls -A calc Makefile integer. c button. c. svn/ Буквы А говорят о том, что Subversion добавил этот элемент в вашу рабочую копию. Теперь у вас есть личная копия каталога /calc хранилища, с одним небольшим добавлением - каталогом. svn, содержащим, служебную информацию, необходимую Subversion.

Транзакции • Работа с хранилищем в Subversion организована в форме транзакций со свойствами атомарности и изоляции. • Система управления версиями гарантирует целостность, непротиворечивость и доступность хранилища в любой момент времени. • Атомарность фиксаций (atomic commits) - изменения в нескольких файлах или директориях фиксируются единой транзакцией, порождая при этом одну ревизию. • В случае неудачной фиксации (сбое или ошибка) система гарантирует что хранилище не окажется в частично изменённом состоянии - в хранилище попадут либо все изменения, либо (при неудаче) ни одного.

• Изоляция гарантирует, что промежуточные состояния хранилища внутри транзакции не видны другим транзакциям и пользователям. Например, если один пользователь фиксирует одной транзакцией изменения в нескольких файлах, то другие пользователи не могут увидеть такого состояния хранилища, в котором часть файлов уже изменена, а часть - не изменена. • Рабочая копия Subversion, в отличие от хранилища, при сбое может оказаться в промежуточном или заблокированном состоянии.

Клиент командной строки Subversion Для того что бы воспользоваться клиентом командной строки, необходимо ввести svn и желаемую подкоманду, а также любые другие параметры командной строки, которые хотите задействовать. Порядок, в котором подкоманды и параметры командной строки должны быть использованы, не играет существенной роли. Например, всё нижеприведённое есть правильное использование svn status: • $ svn -v status • $ svn status -v myfile verbose (-v) - выражает просьбу комментировать процесс выполнения операции как можно более детально. Это может привести к выводу дополнительных полей, подробной информации по каждому файлу или более полной информации о выполняемой операции.

Команды svn Локальные и удалённые формы команд Все команды клиента Subversion можно разделить на следующие группы: • модифицирующие рабочую копию; • модифицирующие хранилище; • модифицирующие и рабочую копию, и хранилище; • не модифицирующие ничего.

Типичная итерация рабочего цикла с Subversion: • Обновление рабочей копии из хранилища - svn update. • Создание рабочей копии из хранилища - svn checkout. • Изменение рабочей копии: - изменения директорий и информации о файлах производится средствами Subversion, - изменения содержимого файлов производятся текстовыми редакторами, средствами разработки и т. п. (Subversion никак не задействован). - новые (еще не зафиксированные в хранилище) файлы и директории нужно добавить - svn acid, то есть передать под управление Subversion.

- если файл или директорию в рабочей копии нужно удалить, переименовать, переместить или скопировать необходимо использовать: svn mkdir, svn delete, svn move, svn copy; - просмотр состояния рабочей копии и локальных (ещё не зафиксированных) изменений svn info, svn status, svn diff; - любые локальные изменения, если они признаны неудачными, можно откатить svn revert. - фиксация своих изменений (и/или результатов слияния) в хранилище (svn commit).

Краткий справочник svn Создание хранилища svnadmin create – создается новый пустой репозиторий Синтаксис svnadmin create REPOS_PATH Описание Создается новый пустой репозиторий в указанном месте. Если директорий не существует, то он создается.

Создание рабочей копии svn checkout (svn co) Синтаксис svn checkout URL[@REV]. . . [PATH] Описание Создает рабочую копию на основе данных из хранилища (извлечение файлов проекта из репозитория).

Изменение файлов и директорий в рабочей копии svn delete - удаляет объект из рабочей копии или хранилища. Синтаксис svn delete PATH. . . (svn del) svn delete URL. . . Описание Объекты определенные через PATH вносятся в план удаления следующей фиксацией изменений. Объекты определенные через URL сразу же фиксируются как удаленные.

svn move (svn mv) Синтаксис svn move SRC DST Описание Перемещает файл или директорий в рабочую копию или репозиторий.

svn copy (svn cp) Синтаксис svn copy SRC DST Описание Копирует файл в рабочей копии или в хранилище. SRC и DST могут быть путями как внутри рабочей копии, так и URL внутри хранилища.

svn update (svn up) Синтаксис svn update [PATH. . . ] Описание Обновляет содержимое локальной копии до самой последней версии из репозитория или до исходной версии, если ревизий не было. Можно получить более раннюю версию файла используя параметр –r. svn update -r номер_ревизии имя_файла

svn commit (svn ci) ( «ci» сокращение от «check in» , a не «co» - сокращения для «checkout» ) Синтаксис svn commit file_name Описание Фиксирует сделанные изменения рабочей копии в хранилище (отправляет файл/папку в репозиторий). Изменяет как рабочую копию, так и хранилище. Порядковый номер отправки данных в репозиторий присваивается соответствующей ревизии.

svn revert Синтаксис svn revert file_name Описание «Откатывает» локальные изменения файла и разрешает конфликтные ситуации (выгружает из репозитория последний залитый командой commit файл). svn revert -R - откатывает все локальные изменения файлов

svn add file_name - добавление файла в репозиторий. svn diff file_name - показывает локальные изменения в файле построчно. svn diff -r N: M file_name - то же, но между ревизиями N и M. svn list URL - просмотр каталога/каталогов репозитория. URL-адрес представляет собой строку вида: протокол: //имя сервера/путь (svn: //eniac/sandbox) svn log file_name - список ревизий, в которых изменялся данный файл.

svn status - отображение изменений в локальной копии относительно репозитория. svn log file_name - список ревизий с комментариями. svn rename old_f_n new_f_n - переименование файла в репозитории. svn cat -r N file_name - отображение содержимого файла из данной ревизии. svn help command_name - справка по команде

Цикл работы с ветвями • создание ветви (svn сору); • переключение рабочей копии на другую ветвь (svn switch) или создание новой рабочей копии путём закачки (svn checkout). • svn switch - используется для того, чтобы переключить имеющуюся рабочую копию на другую ветвь. В результате переключения служебные данные рабочей копии изменяются так, как будто эта рабочая копия получена операцией svn checkout из той ветви, на которую она переключена. • объём сетевого трафика меньше, чем при svn checkout, так как передается только разница между данными в рабочей копии и целевой ветвью; • изменение файлов и директорий в рабочей копии, фиксация этих изменений (svn commit); • копирование в ветвь свежих изменений из родительской ветви, сделанных после ветвления (svn merge, svn commit). • svn merge - копирование набора изменений между ветвями - используется для слияния. удаление ветви (svn delete), если её жизненный цикл закончен.