Журнал LinuxFormat - перейти на главную

LXF120:Контроль версий

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(викификация, оформление, иллюстрация)
 
Строка 590: Строка 590:
 
режимы
 
режимы
 
настройки.
 
настройки.
 +
 +
===''Subversion''===
 +
 +
: Централизованная система, призванная устранить часть проблем ''CVS''.
 +
* '''Сайт''' http://subversion.tigris.org
 +
* '''Лицензия''' Apache License
 +
* '''Применяется в''' ''KDE, Python, Ruby, Mono, Google Code''
 +
 +
''Subversion'' создавалась
 +
на смену
 +
популярной
 +
''CVS'', чтобы
 +
ликвидировать
 +
самые
 +
заметные
 +
недостатки
 +
предшественницы. Как и ''CVS'', система работает
 +
в режиме
 +
клиент–сервер.
 +
Центральный
 +
репозиторий
 +
может
 +
быть локальным
 +
(доступ
 +
через
 +
'''file://''') или удаленным
 +
(доступ через
 +
'''http://''', '''https://''' или
 +
собственные
 +
протоколы
 +
'''svn://''' и '''svn+ssh://''').
 +
 +
В отличие
 +
от ''Bazaar'', здесь перед
 +
началом
 +
работы
 +
необходимо
 +
создать
 +
центральный
 +
репозиторий
 +
(локальный
 +
или удаленный);
 +
поэтому
 +
процесс
 +
передачи
 +
файлов
 +
под контроль
 +
системы
 +
чуть более
 +
трудоемок.
 +
Покончив
 +
с ним, вы заново
 +
выписываете
 +
данные
 +
из репозитория,
 +
чтобы
 +
получить
 +
копию
 +
для
 +
дальнейшей
 +
работы.
 +
 +
Что касается
 +
цикла
 +
«изменение/проверка/фиксация» (внесение
 +
правок
 +
в файл, проверка
 +
на отсутствие
 +
конфликтов
 +
и отсылка
 +
изменений
 +
на сервер),
 +
команды
 +
и основные
 +
операции
 +
те же, что
 +
применяются
 +
в большинстве
 +
систем управления
 +
версиями.
 +
В принципе,
 +
начав
 +
работу
 +
с одной
 +
из них, вы получаете
 +
ключ ко всем
 +
остальным:
 +
их команды
 +
очень схожи
 +
между
 +
собой.
 +
 +
====Разрешение конфликтов====
 +
 +
{{Врезка|Заголовок=Ресурсы|Содержание=
 +
* '''''Bazaar'''''
 +
Учебник «Bazaar за 5 минут» http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
 +
Руководство по переходу с других аналогичных программ http://bazaar-vcs.org/BzrSwitching
 +
* '''''Git'''''
 +
Официальное руководство ''Git'' http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
 +
Краткий курс по переходу ''SVN–Git'' http://git-scm.com/course/svn.html
 +
* '''''Subversion'''''
 +
Version Control with Subversion, книга O’Reilly, доступная бесплатно онлайн (есть перевод на русский язык) http://svnbook.red-bean.com
 +
 +
* '''Общие сведения об СКВ'''
 +
Статья в Википедии со сравнением разных систем http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
 +
Электронное сообщение Линуса Торвальдса по поводу достоинств распределенных систем http://lwn.net/Articles/246381|Ширина=300px}}
 +
 +
Если
 +
в ''Subversion'' вы сталкиваетесь
 +
с конфликтом,
 +
то перед
 +
отправкой
 +
вашего
 +
файла
 +
необходимо
 +
явно
 +
пометить
 +
его как
 +
разрешенный
 +
(‘resolved’). Иногда это кажется
 +
нудным,
 +
зато
 +
предотвращает
 +
случайное
 +
попадание
 +
конфликтных
 +
данных
 +
в репозиторий
 +
(впрочем,
 +
ничто не мешает
 +
попросту
 +
снять галочку
 +
вместо
 +
реального
 +
разрешения
 +
конфликта!).
 +
 +
Репозитории
 +
могут
 +
иметь ветви
 +
и тэги,
 +
и слить
 +
ветвь с основным
 +
кодом
 +
(обычно
 +
называемым
 +
‘trunk’ – «ствол») достаточно
 +
легко.
 +
Однако
 +
многоуровневое
 +
ветвление
 +
или перекрестные
 +
связи
 +
между
 +
ветвями
 +
осуществляются
 +
«со скрипом» – с такими
 +
выкрутасами
 +
распределенные
 +
системы
 +
справляются
 +
гораздо
 +
лучше.
 +
 +
Можно
 +
сливать
 +
или разделять
 +
репозитории
 +
целиком
 +
– инструмент
 +
администратора
 +
''SVN'' под названием
 +
''svndumpfilter'' позволяет
 +
обрабатывать
 +
проекты
 +
с помощью
 +
фильтра.
 +
И все-таки
 +
''Subversion''
 +
недоступен
 +
присущий
 +
распределенным
 +
системам
 +
уровень
 +
гибкости
 +
и эффективности
 +
в работе
 +
с ветвями.
 +
Не существует
 +
встроенных
 +
команд, позволяющих
 +
взять патч и встроить
 +
его в дерево
 +
проекта;
 +
это можно
 +
делать
 +
с помощью
 +
внешней команды
 +
''patch'',
 +
но возможны
 +
проблемы
 +
с удаленными
 +
или слитыми
 +
файлами.
 +
 +
====Маркировка изменений=====
 +
 +
''Subversion'' поддерживает файловые метаданные.
 +
В качестве
 +
метки
 +
файлу
 +
можно
 +
присвоить
 +
нечто вполне человекочитаемое
 +
– это прекрасная
 +
возможность
 +
добавить
 +
сопроводительную
 +
информацию.
 +
 +
$ svn propset test «test property value» myfile.txt
 +
$ svn proplist myfile.txt
 +
Properties on 'myfile.txt'
 +
test
 +
$ svn propget test myfile.txt
 +
test property value
 +
 +
Есть некоторые
 +
специальные
 +
свойства,
 +
названия
 +
которых
 +
начинаются
 +
с '''svn:''' – этот префикс
 +
здесь находится
 +
«на особом
 +
положении». Например,
 +
если
 +
установить
 +
для какого-либо
 +
файла
 +
свойство
 +
'''svn:ignore''', то он будет
 +
игнорироваться
 +
системой.
 +
 +
Как и в ''Bazaar'' или ''Git'', поддерживаются
 +
«хуки» (скрипты,
 +
исполняемые
 +
по поводу
 +
определенных
 +
событий).
 +
Это может
 +
пригодиться,
 +
например,
 +
для тестовой
 +
сборки
 +
кода
 +
перед
 +
фиксацией
 +
изменений
 +
в репозитории;
 +
для
 +
удаления
 +
лишних пробелов;
 +
для замены
 +
пробелов
 +
на знаки
 +
табуляции
 +
или наоборот;
 +
для отправки
 +
электронных
 +
сообщений
 +
коллегам
 +
по случаю
 +
фиксации
 +
новых
 +
файлов.
 +
И вообще
 +
для выполнения
 +
любой
 +
задачи,
 +
на которую
 +
у вас хватит
 +
воображения
 +
и способностей
 +
к скриптописанию!

Версия 09:37, 23 июня 2010

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

Управление и контроль

Джульетта Кемп оценивает трех главных претендентов на должность менеджера изменений в ваших данных: Bazaar, Subversion и Git.

Системы контроля версий (СКВ) необходимы при коллективной работе над проектами, но весьма полезны и для предпочитающих сольную деятельность. Отслеживание сделанных изменений обеспечит вам откат к одной из прежних версий, если вы случайно что-нибудь испортите.

Со времени выхода устаревшей CVS появилось множество новых вариантов – какой же из них предпочесть? Распределенную систему или централизованную? Мы рассмотрим самые известные реализации – Bazaar, Subversion и Git, чтобы вы осознанно выбрали наиболее подходящую именно вашим нуждам, будь это крупный проект, любительское программирование, отслеживание изменений в конфигурационных файлах или что-нибудь более экзотичное.

Клиент–сервер против распределенки

Существует два основных типа систем контроля версий: клиент– серверные и распределенные. Бывают и чисто локальные системы, типа RCS, которые действуют исключительно в рамках одной машины, но сейчас они применяются редко: иметь дело с современными разновидностями в любом случае и проще, и удобнее.

Клиент–серверные системы работают в централизованном режиме: на центральном сервере существует текущая копия проекта, из которой «выписывает» (‘checkout’) данные локально работающий пользователь. Внеся желаемые изменения, он (или она) обновляет локальную копию с сервера (чтобы учесть изменения, которые успели сделать за это время другие пользователи), разрешает конфликты, если таковые возникают, а затем фиксирует (‘commit’) свою версию данных в центральном репозитории. После этого внесенные изменения становятся доступны для выписки другими людьми.

Распределенные системы построены по принципу одноранговой сети – репозиторий у каждого свой, а работа синхронизируется за счет взаимообмена пакетами изменений в форме заплат («патчей») или слияния ветвей проекта. На практике большинство мало-мальски значительных проектов имеют одну копию, которая считается главной ветвью разработки; но это скорее социальное различие, чем техническое.

Оба варианта имеют и достоинства, и недостатки. Вот некоторые из преимуществ распределенных СКВ:

  • Обеспечивается полное резервное копирование кодовой базы и истории изменений для каждой ветви проекта; возможно существование нескольких ветвей.
  • Упрощается работа без подключения к Интернету, так как изменения можно до поры фиксировать в локальном хранилище.
  • Проще взаимодействовать с коллегами: для этого не нужно обращаться к централизованной системе.
  • Легче создавать и ликвидировать ветви разработки: тем самым упрощается проведение экспериментов в ходе развития проекта.
  • Есть мнение, что такой способ более демократичен, и позволяет вовлекать в проекты большее число участников.
  • Можно организовать несколько «центральных» ветвей с различной специализацией (например, стабильную, текущую и релиз).
  • Фиксация изменений, просмотр истории и другие подобные операции происходят быстрее: для них не нужен доступ к центральному серверу.
  • Упрощается слияние нескольких частей проекта.

Централизованные СКВ тоже обладают рядом достоинств:

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

Короче, внимания заслуживают оба варианта, хотя в наши дни популярность набирают именно распределенные системы.

Bazaar

Распределенная система не без способностей к централизации.

Bazaar (в командной строке – bzr) – распределенная система, называемая авторами «СКВ, задуманной для людей». Она рассчитана на поддержку рабочих процессов разнообразных типов и предоставляет вам значительную свободу в выборе способа работы и управления версиями. Возможно использование Bazaar совместно с другими аналогичными системами (например, CVS или Subversion).

Применяя Bazaar в распределенном сценарии, вы создаете по ветви на каждую новую функцию (их называют ‘task branches’ – ветви для задачи), а для отправки изменений на сервер используется локальная ветвь-зеркало. В централизованной модели изменения периодически отправляются непосредственно на общий сервер. Девиз команды разработчиков Bazaar – «не стоит прогибаться под причуды ПО, пускай ПО прогнется под вас».

Одна из приятных особенностей Bazaar – работая индивидуально, вы не должны (как в Subversion, например) создавать репозиторий, импортировать файлы, а потом выписывать рабочую копию. Вы работаете себе в каталоге проекта, а Bazaar сам отслеживает сделанные изменения. Одно из очевидных неудобств – усложнение резервного копирования: следует либо держать все проекты внутри главного каталога, либо обеспечить регулярное сохранение абсолютно всех каталогов (кстати, идея сама по себе неплохая). Кроме того, ненароком ошибившись в команде rm -rf, легко сгубить репозиторий. Начать проект очень просто: вместо импорта и последующей выписки кода достаточно инициализировать проект внутри его собственного каталога. При желании работать в более централизованном режиме можно создать репозиторий в отдельном каталоге и выписать ветвь из него. Это делается всего лишь одной командой: init-repo.

Работа оффлайн

Распределенная природа Bazaar позволяет работать и вносить изменения, не подключаясь к Сети. В централизованных системах это тоже возможно с помощью локального репозитория, но его совмещение с основным сервером чревато сложностями. В Bazaar локальный контроль версий весьма удобен: вы загружаете основной проект командой bzr branch, и на вашей машине создается его локальная ветвь. Можно работать внутри нее, а можно создавать подветви и фиксировать изменения в них с той частотой, какая вам заблагорассудится. Команда bzr merge сольет вашу ветвь проекта с родительской, а завершив работу над кодом, нетрудно создать заплатку для отправки «наверх» командой bzr send -o patchname.patch. Ответственный за родительскую ветвь проекта может внести в нее ваш патч – а может и не внести; для этого используются те же команды, что и при слиянии ветвей. Теоретически Bazaar может обходиться без центрального дерева, но на практике большинство проектов имеют такое и сливают с ним отдельные ветви.

Алгоритм объединения ветвей Bazaar позволяет осуществлять множественное слияние, а также определять последнего общего предка ветвей. Возможно не только объединение, но и «сплетение» различных ветвей, а также разрешение весьма непростых конфликтных ситуаций. Но требование общего предка у ветвей является обязательным (а вот Git умеет совмещать совершенно не родственные ветви).

Bazaar поддерживает выборочное слияние, при котором проводится не полное, а частичное совмещение изменений ветви (например, только до версии 104, или только из версий 105–107). Есть возможность отложить свои изменения до поры, изъяв их из рабочего дерева (например, чтобы упростить слияние с крупным обновлением, произошедшим в родительской ветви), а затем вернуть в проект. Это удобно, если вы работаете над несколькими заплатками, либо хотите воспользоваться правками коллег. Как и в Subversion, можно применять «хуки» (‘hooks’; это скрипты, исполняемые перед определенными действиями или после них).

Полезное качество для крупных проектов – интеграция с системами отслеживания ошибок. С помощью ключа --fixes можно привязать к изменению номер ошибки в системах разных типов (поддерживаются Bugzilla, Launchpad, Trac, Roundup и пр.). Например, строка: 

bzr commit -- fixes project:23400 -m «Stores user birthdates properly»

добавит в журнал ссылку на ошибку № 23400 трекера Bugzilla для проекта project. Для Bugzilla и Trac поддерживаются упрощенные режимы настройки.

Subversion

Централизованная система, призванная устранить часть проблем CVS.

Subversion создавалась на смену популярной CVS, чтобы ликвидировать самые заметные недостатки предшественницы. Как и CVS, система работает в режиме клиент–сервер. Центральный репозиторий может быть локальным (доступ через file://) или удаленным (доступ через http://, https:// или собственные протоколы svn:// и svn+ssh://).

В отличие от Bazaar, здесь перед началом работы необходимо создать центральный репозиторий (локальный или удаленный); поэтому процесс передачи файлов под контроль системы чуть более трудоемок. Покончив с ним, вы заново выписываете данные из репозитория, чтобы получить копию для дальнейшей работы.

Что касается цикла «изменение/проверка/фиксация» (внесение правок в файл, проверка на отсутствие конфликтов и отсылка изменений на сервер), команды и основные операции те же, что применяются в большинстве систем управления версиями. В принципе, начав работу с одной из них, вы получаете ключ ко всем остальным: их команды очень схожи между собой.

Разрешение конфликтов

Если в Subversion вы сталкиваетесь с конфликтом, то перед отправкой вашего файла необходимо явно пометить его как разрешенный (‘resolved’). Иногда это кажется нудным, зато предотвращает случайное попадание конфликтных данных в репозиторий (впрочем, ничто не мешает попросту снять галочку вместо реального разрешения конфликта!).

Репозитории могут иметь ветви и тэги, и слить ветвь с основным кодом (обычно называемым ‘trunk’ – «ствол») достаточно легко. Однако многоуровневое ветвление или перекрестные связи между ветвями осуществляются «со скрипом» – с такими выкрутасами распределенные системы справляются гораздо лучше.

Можно сливать или разделять репозитории целиком – инструмент администратора SVN под названием svndumpfilter позволяет обрабатывать проекты с помощью фильтра. И все-таки Subversion недоступен присущий распределенным системам уровень гибкости и эффективности в работе с ветвями. Не существует встроенных команд, позволяющих взять патч и встроить его в дерево проекта; это можно делать с помощью внешней команды patch, но возможны проблемы с удаленными или слитыми файлами.

Маркировка изменений=

Subversion поддерживает файловые метаданные. В качестве метки файлу можно присвоить нечто вполне человекочитаемое – это прекрасная возможность добавить сопроводительную информацию. 

$ svn propset test «test property value» myfile.txt
$ svn proplist myfile.txt
Properties on 'myfile.txt'
test
$ svn propget test myfile.txt
test property value

Есть некоторые специальные свойства, названия которых начинаются с svn: – этот префикс здесь находится «на особом положении». Например, если установить для какого-либо файла свойство svn:ignore, то он будет игнорироваться системой.

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

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF120:%D0%9A%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D1%8C_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D0%B9&oldid=10446»
купить
подписаться
Яндекс.Метрика