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

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

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(викификация, оформление, иллюстрация)
 
(Управление и контроль)
 
(не показана 1 промежуточная версия 1 участника)
Строка 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'', поддерживаются
 +
«хуки» (скрипты,
 +
исполняемые
 +
по поводу
 +
определенных
 +
событий).
 +
Это может
 +
пригодиться,
 +
например,
 +
для тестовой
 +
сборки
 +
кода
 +
перед
 +
фиксацией
 +
изменений
 +
в репозитории;
 +
для
 +
удаления
 +
лишних пробелов;
 +
для замены
 +
пробелов
 +
на знаки
 +
табуляции
 +
или наоборот;
 +
для отправки
 +
электронных
 +
сообщений
 +
коллегам
 +
по случаю
 +
фиксации
 +
новых
 +
файлов.
 +
И вообще
 +
для выполнения
 +
любой
 +
задачи,
 +
на которую
 +
у вас хватит
 +
воображения
 +
и способностей
 +
к скриптописанию!
 +
 +
===''Git''===
 +
 +
: Чрезвычайно распределенная, и очень быстрая.
 +
* '''Сайт''' http://git-scm.com
 +
* '''Лицензия''' GPL
 +
* '''Применяется в''' ядре Linux, Gnome, ''Perl, X.org, VLC, Android''
 +
 +
Как и ''Bazaar, Git'' – это вариант
 +
распределенной
 +
СКВ; изначально
 +
она была
 +
создана
 +
Линусом
 +
Торвальдсом
 +
[Linus Torvalds] для ядра
 +
Linux.
 +
 +
Одна
 +
из ключевых
 +
особенностей
 +
''Git'' – поддержка
 +
нелинейного
 +
процесса
 +
разработки:
 +
идея состоит
 +
в том, что изменения
 +
вливаются
 +
неоднократно,
 +
по мере
 +
проверок
 +
ответственными
 +
лицами
 +
(именно
 +
так и происходит
 +
развитие
 +
Linux). На практике
 +
это значит
 +
очень простое
 +
слияние ветвей
 +
и деревьев,
 +
даже
 +
если
 +
они никак
 +
не связаны
 +
между
 +
собой
 +
и не имеют
 +
общих
 +
предков.
 +
Можно
 +
даже
 +
встраивать
 +
код неопределенной
 +
версии
 +
в существующее
 +
версионное
 +
дерево:
 +
на такие
 +
фокусы
 +
не способны
 +
ни ''Bazaar'', ни ''Subversion''.
 +
Кроме
 +
того,
 +
в ''Git'' значительное
 +
внимание уделяется
 +
скорости,
 +
быстроте
 +
работы
 +
с крупными
 +
проектами.
 +
 +
Распределенная
 +
природа
 +
позволяет
 +
''Git'', как и ''Bazaar'', сопровождать
 +
каждую
 +
рабочую
 +
копию
 +
отдельным
 +
репозиторием
 +
(в подкаталоге
 +
'''.git'''), а не полагаться
 +
на одно
 +
централизованное
 +
хранилище,
 +
как делает
 +
''SVN''. Кроме
 +
того,
 +
в этой системе
 +
несложно
 +
создать
 +
новый
 +
проект
 +
– нужно
 +
лишь дать команды
 +
''git init'';
 +
''git add.''; ''git commit'' в его каталоге.
 +
Это, правда,
 +
немного
 +
осложняет
 +
резервное
 +
копирование.
 +
Ну, а при желании
 +
всегда
 +
можно
 +
создать
 +
собственный
 +
вариант
 +
локального
 +
централизованного
 +
репозитория.
 +
 +
====Совместимость====
 +
 +
Как и ''Bazaar, Git'' работает
 +
с ''Subversion'': можно
 +
пользоваться
 +
репозиторием
 +
''Subversion'' непосредственно
 +
в ''Git'' с помощью
 +
команды
 +
''git-svn''. Это очень полезно,
 +
если,
 +
например,
 +
вы хотите
 +
просто
 +
попробовать
 +
систему
 +
или работаете
 +
с проектом
 +
''SVN'',
 +
изменять
 +
который
 +
не следует.
 +
При сильном
 +
сходстве,
 +
команды
 +
имеют
 +
и отличия
 +
от тех, что
 +
используются
 +
в ''Bazaar'' и ''Subversion''.
 +
Есть действительно
 +
классные
 +
улучшения:
 +
например,
 +
''git diff'' автоматически
 +
использует
 +
в качестве
 +
пейджера
 +
команду
 +
''less'', и вам незачем
 +
помнить о соединении
 +
процессов
 +
через
 +
канал.
 +
 +
Также
 +
интересно
 +
обеспечение
 +
безопасности:
 +
история
 +
записывается
 +
таким
 +
образом,
 +
что номера
 +
версий
 +
зависят
 +
от ранее сделанных
 +
изменений.
 +
После
 +
публикации
 +
версии
 +
исправить
 +
ее тайком
 +
невозможно.
 +
 +
На практике
 +
версии
 +
распознаются
 +
по идентификатору
 +
SHA1 ID,
 +
160‑битному
 +
числу
 +
в шестнадцатеричном
 +
формате.
 +
Естественный
 +
недостаток
 +
этого
 +
способа
 +
– длинный
 +
и сложный
 +
номер.
 +
Впрочем,
 +
в ''Git'' есть автодополнение,
 +
да и копирование-вставку
 +
никто
 +
не отменял.
 +
 +
Система
 +
тэгов
 +
в ''Git'' довольно
 +
мощная.
 +
Можно
 +
сопровождать
 +
любой
 +
файл совершенно
 +
произвольным
 +
описанием;
 +
иногда тэг
 +
проекта
 +
содержит
 +
полномерную
 +
документацию.
 +
Сохраняется
 +
имя
 +
автора
 +
тэга,
 +
возможна
 +
защита
 +
PGP-подписью
 +
– то есть обеспечивается
 +
подтверждение
 +
личности
 +
автора,
 +
подлинности
 +
версии,
 +
истории
 +
и дерева
 +
проекта.
 +
 +
В отличие
 +
от манеры ''Subversion'', при слиянии сохраняется
 +
полная
 +
история
 +
изменений
 +
обеих
 +
ветвей;
 +
кроме
 +
того,
 +
ветви
 +
можно
 +
сливать
 +
многократно.
 +
Основной
 +
приоритет
 +
в ''Git'' отдан
 +
гибкости
 +
и возможности
 +
многократного
 +
слияния различных
 +
ветвей
 +
разного
 +
происхождения.
 +
Система
 +
работает
 +
с патчами
 +
(пакетами
 +
изменений)
 +
и обладает
 +
развитой
 +
поддержкой
 +
патчей,
 +
доставляемых
 +
по электронной
 +
почте.
 +
Вы можете
 +
просто
 +
указать
 +
программе
 +
на почтовый
 +
ящик (в формате
 +
mailbox), содержащий
 +
сообщения
 +
с патчами:
 +
они будут
 +
извлечены
 +
и пущены
 +
в дело.
 +
А для работы
 +
с группами
 +
патчей
 +
еще есть инструмент
 +
''StGIT''.
 +
 +
====Хук слева, хук справа====
 +
 +
Как и ''Bazaar'' с ''Subversion, Git'' поддерживает
 +
хуки:
 +
скрипты,
 +
исполняемые
 +
по случаю
 +
некоторых
 +
событий.
 +
Например,
 +
скрипт может
 +
проверять
 +
наличие
 +
лишних пробелов
 +
и, обнаружив
 +
таковые,
 +
прервать
 +
фиксацию;
 +
или разослать
 +
электронные
 +
сообщения
 +
по окончании
 +
процесса
 +
отправки
 +
изменений.
 +
Одно
 +
плохо
 +
– ''Git''
 +
неэкономно
 +
расходует
 +
место:
 +
каждый
 +
объект
 +
в системе
 +
хранится
 +
в виде
 +
отдельного
 +
файла.
 +
Поэтому
 +
файлы,
 +
в целях
 +
экономии,
 +
время
 +
от времени
 +
«пакуются»
 +
друг с другом.
 +
 +
===Вердикт===
 +
 +
Все три рассмотренные
 +
системы
 +
управления
 +
версиями
 +
– замечательные
 +
экземпляры
 +
ПО:
 +
ваш выбор
 +
зависит
 +
от ваших
 +
же потребностей.
 +
 +
При сверхраспределенной
 +
схеме
 +
разработки,
 +
с большим
 +
количеством
 +
независимо
 +
работающих
 +
программистов,
 +
''Git'' обладает
 +
рядом
 +
несомненных
 +
преимуществ.
 +
Для действующих
 +
в одиночку
 +
использование
 +
распределенной
 +
системы
 +
тоже
 +
имеет
 +
смысл, ведь
 +
в этом случае
 +
так просто
 +
создать
 +
новый
 +
репозиторий
 +
(даже
 +
из существующего
 +
каталога).
 +
А ведь чем проще
 +
пользоваться
 +
системой,
 +
тем
 +
выше
 +
вероятность
 +
ее выбора.
 +
Только
 +
не забывайте
 +
о регулярном
 +
резервном копировании!
 +
 +
Для более
 +
централизованных
 +
проектов
 +
лучше
 +
подходит
 +
''Subversion'' – поддержка
 +
для
 +
этой системы
 +
тоже
 +
неплохая.
 +
''Bazaar'' служит
 +
мостиком
 +
между
 +
централизованными
 +
и распределенными
 +
системами:
 +
несмотря
 +
на распределенную
 +
природу,
 +
в этой системе
 +
можно
 +
вести и более
 +
централизованную
 +
работу
 +
(если
 +
такая
 +
вдруг понадобится).
 +
 +
К счастью,
 +
затраты
 +
на эксперименты
 +
со всеми
 +
тремя
 +
вариантами
 +
(особенно
 +
распределенными)
 +
невысоки:
 +
просто
 +
возьмите
 +
себе
 +
экземпляр,
 +
да и попробуйте.
 +
Не понравится
 +
– можно
 +
потом
 +
перейти
 +
на другую
 +
систему. '''LXF'''

Текущая версия на 10:05, 23 июня 2010

Содержание

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

Джульетта Кемп оценивает трех главных претендентов на должность менеджера изменений в ваших данных: 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, поддерживаются «хуки» (скрипты, исполняемые по поводу определенных событий). Это может пригодиться, например, для тестовой сборки кода перед фиксацией изменений в репозитории; для удаления лишних пробелов; для замены пробелов на знаки табуляции или наоборот; для отправки электронных сообщений коллегам по случаю фиксации новых файлов. И вообще для выполнения любой задачи, на которую у вас хватит воображения и способностей к скриптописанию!

[править] Git

Чрезвычайно распределенная, и очень быстрая.
  • Сайт http://git-scm.com
  • Лицензия GPL
  • Применяется в ядре Linux, Gnome, Perl, X.org, VLC, Android

Как и Bazaar, Git – это вариант распределенной СКВ; изначально она была создана Линусом Торвальдсом [Linus Torvalds] для ядра Linux.

Одна из ключевых особенностей Git – поддержка нелинейного процесса разработки: идея состоит в том, что изменения вливаются неоднократно, по мере проверок ответственными лицами (именно так и происходит развитие Linux). На практике это значит очень простое слияние ветвей и деревьев, даже если они никак не связаны между собой и не имеют общих предков. Можно даже встраивать код неопределенной версии в существующее версионное дерево: на такие фокусы не способны ни Bazaar, ни Subversion. Кроме того, в Git значительное внимание уделяется скорости, быстроте работы с крупными проектами.

Распределенная природа позволяет Git, как и Bazaar, сопровождать каждую рабочую копию отдельным репозиторием (в подкаталоге .git), а не полагаться на одно централизованное хранилище, как делает SVN. Кроме того, в этой системе несложно создать новый проект – нужно лишь дать команды git init; git add.; git commit в его каталоге. Это, правда, немного осложняет резервное копирование. Ну, а при желании всегда можно создать собственный вариант локального централизованного репозитория.

[править] Совместимость

Как и Bazaar, Git работает с Subversion: можно пользоваться репозиторием Subversion непосредственно в Git с помощью команды git-svn. Это очень полезно, если, например, вы хотите просто попробовать систему или работаете с проектом SVN, изменять который не следует. При сильном сходстве, команды имеют и отличия от тех, что используются в Bazaar и Subversion. Есть действительно классные улучшения: например, git diff автоматически использует в качестве пейджера команду less, и вам незачем помнить о соединении процессов через канал.

Также интересно обеспечение безопасности: история записывается таким образом, что номера версий зависят от ранее сделанных изменений. После публикации версии исправить ее тайком невозможно.

На практике версии распознаются по идентификатору SHA1 ID, 160‑битному числу в шестнадцатеричном формате. Естественный недостаток этого способа – длинный и сложный номер. Впрочем, в Git есть автодополнение, да и копирование-вставку никто не отменял.

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

В отличие от манеры Subversion, при слиянии сохраняется полная история изменений обеих ветвей; кроме того, ветви можно сливать многократно. Основной приоритет в Git отдан гибкости и возможности многократного слияния различных ветвей разного происхождения. Система работает с патчами (пакетами изменений) и обладает развитой поддержкой патчей, доставляемых по электронной почте. Вы можете просто указать программе на почтовый ящик (в формате mailbox), содержащий сообщения с патчами: они будут извлечены и пущены в дело. А для работы с группами патчей еще есть инструмент StGIT.

[править] Хук слева, хук справа

Как и Bazaar с Subversion, Git поддерживает хуки: скрипты, исполняемые по случаю некоторых событий. Например, скрипт может проверять наличие лишних пробелов и, обнаружив таковые, прервать фиксацию; или разослать электронные сообщения по окончании процесса отправки изменений. Одно плохо – Git неэкономно расходует место: каждый объект в системе хранится в виде отдельного файла. Поэтому файлы, в целях экономии, время от времени «пакуются» друг с другом.

[править] Вердикт

Все три рассмотренные системы управления версиями – замечательные экземпляры ПО: ваш выбор зависит от ваших же потребностей.

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

Для более централизованных проектов лучше подходит Subversion – поддержка для этой системы тоже неплохая. Bazaar служит мостиком между централизованными и распределенными системами: несмотря на распределенную природу, в этой системе можно вести и более централизованную работу (если такая вдруг понадобится).

К счастью, затраты на эксперименты со всеми тремя вариантами (особенно распределенными) невысоки: просто возьмите себе экземпляр, да и попробуйте. Не понравится – можно потом перейти на другую систему. LXF

Персональные инструменты
купить
подписаться
Яндекс.Метрика