Презентация по VCS

Ссылки сюда (3) →

Slide Show

Автор

Виталий Филиппов

Дополнительный нижний колонтитул

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

@@

Виталий Филиппов, CUSTIS

Контроль версий: Зачем? @@

• Бэкап на случай утери кода
  спонсоры: rm -rf /, Джамшуты, школоло с вирусами
• Неблокирующие совместные правки, синхронизация
• Поиск виновного (annotate/blame)
• Code review
• Поддержка старых версий

История VCS @@

…по большей части свободных.

Терминология @@

Метка	tag	именованная версия проекта
Ветка	branch	«метка, имеющая историю развития»
Репозиторий	repository	хранилище версий
Рабочая копия	work copy	копия проекта, связанная с репозиторием
Коммит, фиксация	commit, checkin	сохранение изменений в репозитории
Чекаут, извлечение	checkout	получение рабочей копии (без истории)
Push, pull		отправка/получение изменений в/из другого репозитория
cvs HEAD svn trunk git master		Основная ветка

На заметку: интерфейсы @@

• $ командная строка
• Web-интерфейсы (для просмотра и поиска).
• GUI, обычные и встроенные в IDE.

Локальные VCS @@

Простейший вариант — архивы или папочки со старыми версиями.
(не надо так делать)

SCCS (1972), RCS (1985).

Diff, patch, merge @@

• diff (1970) — подсчёт разницы между текстовыми файлами (алгоритм)
• patch (1984) — применение этих разниц — патчей

  Автор — Лэрри Уолл (создатель Perl’а)

• rcsmerge (1982), diff3 (поновее) — слияние изменений

Как это было в RCS @@

Команды RCS называются просто co и ci.

«Репозиторий» для каждого файла «свой» — файл.txt,v является «репозиторием» для файла.txt. Лежит либо прямо рядом, либо в подпапке RCS.

<создали файл.txt>
$ ci -t-'В этом файле содержится мудрость Господня' файл.txt
файл.txt,v  <--  файл.txt
initial revision: 1.1
done
$ co файл.txt # на посмотреть
файл.txt,v  -->  файл.txt
revision 1.1
done
$ co -l файл.txt # блокируем файл (хотим править)
файл.txt,v  -->  файл.txt
revision 1.1 (locked)
done
<...правим...>
$ ci -m'Мудрость исправлена' файл.txt
файл.txt,v  <--  файл.txt
new revision: 1.2; previous revision: 1.1
done

Централизованные VCS %% @@

• История версий хранится на центральном сервере
• Рабочие копии создаются на компьютерах разработчиков

CVS (1990), Subversion (2000).

CVS: прикрученный к RCS сервер @@

Справедливо решили, что файлы и репозиторий вперемешку — не дело!

Репозиторий теперь хранится отдельно, а то и удалённо. Однако, всё равно пофайлово.

$ export CVSROOT=/path/to/new/repo # задаём путь к репозиторию
$ cvs init # создаём репозиторий
cvs init: Repository /path/to/new/repo initialised
$ cvs import module custis # импорт текущей папки
N module/file
...

No conflicts created by this import
$ cvs co module # извлекаем
cvs checkout: Updating module
U module/file
<...правим файлы...>
cd module
$ cvs ci -m 'Сообщение об исправлении'
cvs commit: Examining .
Checking in file;
/path/to/repo/mod/file,v  <--  file
new revision: 1.2; previous revision: 1.1
done

CVS: и даже… @@

• …умеет annotate (blame).
• …умеет ветвиться и сливаться, хоть и криво.
• …умеет хуки.
• …имеет ГУИ — например, TortoiseCVS.

Однако…

• Репозиторий пофайловый на основе RCS
  ☹ версии у файлов отдельные (и дурацкие типа 1.128.2.5)
  ☹ коммиты неатомарны
• Протокол сервера неудобен
• Устарел в целом (различные мелкие недостатки)

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

Subversion: «CVS Done Right» @@

☺ Всё поновее, пошустрее, поудобнее (форматы, протоколы…)
☺ Общий номер ревизии, атомарные коммиты
☺ Права доступа**
☺ UTF-8, mime типы, свойства файлов
? Копирование вместо веток/меток; ☺ mergeinfo

Web:

ГУИ: RabbitVCS, TortoiseSVN
(для конченых виндузятников) VisualSVN, AnkhSVN

---

** Благодаря оным — горячо любим компаниями, в том числе и Этой.

Subversion: однако… @@

☹ Нет контроля целостности
☹ Не очень удобные ветвления/слияния
☹ Нет родного Web-интерфейса
☹ (?) Централизованная
☹ Торвальдс: «There is no way to do CVS right»

Распределённые VCS @@

• Каждая копия содержит всю историю ревизий
• Возможен обмен между любыми участниками
• Лёгкость ветвления и слияния

TLA / GNU Arch (2001); Monotone, Darcs (2003); Git, Mercurial (2005); Bazaar (2007).

* Ещё были выкидыши типа SVK

Пример ветвления — Feature Branches %% @@

Смысл: каждая доработка в отдельной ветке.

Создаются → правятся → сливаются обратно в trunk.

Нюанс @@

Слияние отменить невозможно!
⇒ разрешайте конфликты в ветке «фичи», а не в «мастере».

Как можно обмениваться: дерево доверия %% @@

(Репозитории или ветки)

Эмуляция централизации %% @@

Можно работать с DVCS, почти* как с централизованной!

---

* Вынеся за скобки отсутствие пофайловости.

Минусы DVCS @@

• Репозиторий пухнет

  Хочешь Андроид? Слей 6 гигов!

• Отсутствие пофайловости (и ☺, и ☹)
• Бывает нужно переписывать историю всех репозиториев в Москве

Откуда ноги растут? %% @@

Из разработки ядра Linux!

Linux @@

• 1992—2002: тарболлы и патчи

  «и это была лучшая система контроля версий, чем CVS»

• 2002—2005 — BitKeeper

  проприетарщики такие проприетарщики

  обиделись на «реверс-инжиниринг» — команду help на сервере

• Monotone и Darcs уже тоже были

  но первый O(n³), второй O(eⁿ)

Из идей Monotone и BitKeeper родились Git (Linus Torvalds) и Mercurial (Matt Mackall).

⇒         ⇒

Git и Mercurial @@

• Git: Tracking Branches (и ☺, и ☹)
• Mercurial: Гораздо интиутивнее система команд (см. сюда)
• Git: В целом быстрее, но не всегда, плюс имеет задержки GC
• Git: Хранит эффективнее в 1.5-2 раза (в нём граф объектов)
• Мощность функционала ≈
• Mercurial: Python, вместо Gitовского микса C+Bash+Perl
• Git: Есть Gerrit!

Bazaar @@

Bazaar — творение Ubuntu (с БДж и Ш)

☹ 1 клон = 1 ветка ☹☹☹
☹ Принудительные слияния, один HEAD, пляски ревизий ☹☹☹
☺ Есть легковесные Checkout’ы а-ля SVN
☹ Не умеет ASCII-графы рисовать :-D
☺ Зато успешно хавает жирные текстовые файлы.

Rebase @@

Когда не хочется или невозможно мержить.

Очередь патчей (Patch Queue) @@

Стандартная тема: приём сторонних патчей в свободный проект.

• Вася пофиксил баг в Mercurial и ещё добавил фичу
• Сказал hg commit всего вместе
• Отправляет Мэтту по почте результат hg export
• А Мэтт говорит:
  1. поправь вот тут и вот там
  2. а ещё раздели патч на багфикс и фичу!
• …и что делать Васе — клонировать заново?

На помощь идёт MQ! @@

Mercurial Queues, аналоги — StGIT, bzr-loom. Все по мотивам quilt.

Разделение патчей:

$ hg qimport -n feature -r . # превратить текущую правку в патч
<...выделяем и удаляем багфикс...>
$ hg diff --reverse > P2
$ hg qrefresh # из feature убран багфикс
$ hg qimport -n bugfix -r P2 -P # создаём патч-багфикс

Правка патчей @@

Для работы над одним из патчей:

$ hg qpop # временно убираем багфикс для работы над фичей
<...вносим правки Мэтта...>
$ hg qrefresh # сохраняем правки
$ hg qpush # возвращаем багфикс

Если проект по пути обновится:

$ hg qpop -a; hg up; hg qpush -a

Мэтт тем же MQ импортирует (qimport) и принимает (qfinish) патчи.

Заметки для себя

• Интерфейсы
  • Commandline
  • GUI: tortoise{cvs, svn, hg, git}, msysgit
  • Web: viewvc, hgweb, gitweb, gerrit
  • Хостинги: google code, bitbucket, github, launchpad
• MQ, патчи
• Практика
  • Feature Branch
  • SVN
  • Mercurial
  • Git
• Commit Early Commit Often! Хотя бы каждый день :-)