Исторически все развивалось так, что системы контроля версий были добавлены в курс ~ в 2008-м году, когда ещё не было Git'ов, Mercurial'ов и пр., а SVN занимал 90% рынка новых стартующих проектов. Subversion уже длительное время использовался в «Интервэйле» (как минимум с 2004 года) и этот опыт напрямую переносился. Кроме того, система организации каталогов проектов и подключения библиотек была взята в определяющем так, как это было организовано в компании.
По теме была запланирована одна лекция, которая обычно длилась 1-1.5 пары. Это была первая тема, так как все, что делалось в дальнейшем, делалось под контролем SVN.
SVN-сервер находился на кафедральном сервере и студенты имели доступ к нему из любой точки ВУЗа. Каждый из учащихся получал свой репозиторий, с которым он работал в течение семестра. На лабораторных в подавляющем числе случаев использовался интерфейс TortoiseSVN.
Удержание фокуса
Каждая лабораторная должна быть в конце зафиксирована в репозитории в виде тега и это проверялось при сдаче. Приучаем к отработке всего цикла — checkout, правки одной малой задачи, commit с описанием что было сделано. Для многих действий нужно было делать все в первых работ step-by-step, что, зачем, как.
checkout на локальные машины, а не на внешние сервера. Много копий (локальных и в репозитории) это плохо — то что закоммичено, того не вырубишь топором — переход на новую идеологию хранения исходников.
Установка под контроль сразу же после появления исходных файлов. За контроль EXE/OBJ/… давать по рукам и заставлять снимать из под контроля.
Подробности
Со временем пришел к тому, что изложение понятий систем контроля версий нужно начинать издалека. Это не что-то страшное, а близкое, только на другом языке.
Сначала рассмотрение понятия проекта — нечто с определенной целью в виде некоторой активности в течение времени. Подготовка к вечеринке, выполнение курсового, поход на рыбалку, регулярная уборка в доме — все это проекты (будущий проект в svn).
Каждый проект с чего-то начинается и имеет последовательность действий. Каждое малое действие может быть выделено и описано отдельно (будущие ревизии и их описание в svn).
Если рассмотреть проект во времени, то его состояние постоянно изменяется по мере выполнения каких-либо действий. Таким образом проект не просто набор чего-то, а что-то, что существует и изменяется во времени (будущий контроль проекта svn во времени).
С точки зрения контроля проекта во времени у нас могут возникать вопросы: в каком состоянии был проект в момент X? кто сделал действие Y? что изменялось в проекте за месяц Z? что надо сделать, чтобы отменить изменения за позапрошлую неделю? Данные проблемы надо как-то решать, и решение зависит от организации контроля проекта во времени (будущие типичные задачи при работе в svn).
Как мы можем контролировать проект во времени? Завести блокнот, создать ряд каталогов на диске, держать в голове, … у каждого способа есть свои достоинства и недостатки (блокнот копировать сложно но он надежный, компьютер доступен не всегда, но он быстр, в голове можно и забыть, но это всегда под рукой).
Так что такое системы контроля версий? Это вспомогательные инструменты, помогающие автоматизировать описанный выше процесс, тем самым уменьшить количество ошибок, предоставить удобные функции и др..
С точки зрения автоматизации уже имеются всем знакомые системы контроля версий, которые помогают нам в этом. Undo/Redo в где угодно (хоть в MS Word), страница в википедии (показываем в онлайне историю правок с датами, комментариями, возможностями сравнения и отката, …). Таких ресурсов много — история изменений одного файла в Dropbox, изменения страниц в pbworks.
И только теперь на сцену выходит Subversion и начинаются слайды.
Понятие архитектуры клиент-сервер. Хранилище одно, оно надежное и доступное отовсюду. Клиентов много, они общаются с хранилищем и сами себе буратины.
Две модели версионирования (блокировка-изменение-разблокировка и копирование-изменение-слияние). Преимущества и недоставки обеих моделей (бинарные файлы и текстовые, возможность слияния, ручное слияние, администраторские проблемы (админ ушел в отпуск, а блокировка осталась)).
Понятие ревизий в Subverison. Ревизии атомарные, инкрементируются только при успешном commit'e. Каждая ревизия — в идеале одна отдельная задача.
Понятие рабочей копии. Копия делается из хранилища по запросу пользователя, может быть сделана везде. Уничтожение копии не страшно, могут потеряться только локальные правки, потому фиксация изменений должна быть частая без висящих локально правок.
Фиксация изменений (commit). Инициирует клиент, дает описание изменений. Все хорошо — фиксируется, плохо — не фиксируется (требуется ручное вмешательство при слиянии, проблемы подключения, …). Описание изменений ассоциируется с ревизией и потом может быть использовано.
Обновление (update). Использование когда возможны внешние правки (например работа в команде).
Откат локальных изменений (revert). Команда отрабатывает локально, без подключения к серверу. Локально всегда хранится копия с последнего checkout'a или update'a, чтобы система знала, что было исправлено локально, и чтобы можно было таким образом откатить изменения.
Понятие контроля файлов в WC. SVN должен знать, что ему контролировать, т.е. каждый файл на диске находится под контролем SVN или нет. Если мы сами создаем файл, то SVN о нем ничего не знает, и при необходимости мы должны ему сказать. Под контроль ставятся только исходные, но не производные (EXE, OBJ, …) файлы. Команды установки код контроль и снятия из-под контроля. Копирование и перемещение в SVN — не создает нагрузку на сервер.
Структура хранилища с точки зрения классики SVN — trunk, tags, branches. Что такое trunk, зачем нужны теги (фиксация стабильной версии, передача конкретной версии заказчику, выделение версии для конкретных работ, …). Понятие branches — выделение отельных веток и слияние (один программист пилит новую функциональность, второй правит баги, и оба друг другу не мешают; отдельные ветки для подпроектов и подзадач, когда требуется дальнейшее развитие).
Описание полного типичного рабочего цикла (checkout, updaten commit).
Свойства в SVN, на примере svn:externals. Подключение внешних ресурсов через externals (иначе не получится), экономия места, переключение externals на другую версию.
По обстоятельствам — демонстрация создания svn-сервера и типичных действий над hello world.
