Личный опыт разработки ПО

До моей первой работы в качестве программиста, я решительно ничего не знал о системах управления версиями, даже данный термин был для меня пустым звуком. Объяснить что это такое и для чего оно вообще нужно, никто не посчитал нужным, поэтому пришлось выяснять это самому. Да, на некоторое время я просто возненавидел сам процесс комита, когда мне говорили, что нужно файлы добавить в таг, я бледнел, а уж когда CVS мне сообщала о конфликте в коде, я просто паниковал. На самом деле это просто еще один полезный инструмент, просто нужно понять для чего он и показать пару приемов. Собственно заметка об этом.

Суть в следующем — где-то на сервере есть хранилище кода (репозиторий), куда вы можете сохранять свой код. Какие это дает преимущества перед хранением кода на своем компьютере?

1. Надежность

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

2. Сохранение истории

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

   Для подобных целей до знакомства с системами управления версиями я периодически архивировал папку с проектом, называя файлы по текущей дате. К сожалению этот подход скорее не работает, чем работает и очень трудоемок. Использование репозитория с кодом полностью снимает эту проблему.

3. Совместная разработка

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

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

Упрощенный алгоритм разработки с применением Subversion

1. Берем из репозитория последнюю версию кода

   Если еще ни разу не брали код

   svn checkout путь_к_хранилищу директория_проекта_на_рабочем_компьютере

   
   или если брали, то просто обновим

   svn update

2. Добавляем новый функционал или исправляем ошибку

3. Сохраняем изменения в репозиторий

   svn commit -m "Пояснения к комиту"

Как видите достаточно двух команд.

Какую систему контроля версий будем рассматривать и почему?

Я имею опыт работы с CVS и Subversion. Хочу сказать, что Subversion (она же SVN) полностью меня устраивает, так как она бесплатна, имеет хорошую документацию и удобна в работе. Поэтому как вы уже догадались далее речь пойдет именно о ней.

Да я знаю об альтернативах, например о Git. Но SVN работает, работает надежно, есть поддержка со стороны важных инструментов (багтрекеров и т.д.), не требует для работы существенных умственных усилий. Все плюсы распределенных систем управления версиями проявляются при совместной разработке множества самостоятельных разработчиков, для одной команды достаточно централизованного хранилища.

CVS мы не рассматриваем так как эта система довольно устаревшая и SVN является ей достойной заменой.

Что нам понадобится?

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

Получение кода

Логично, что перед тем как начать работать с кодом, его надо получить. В заметке я не рассматриваю создание репозитория, это тема другой статьи, сейчас просто предположим, что репозиторий уже создан.

Администратор должен предоставить путь к репозиторию (что-то вроде https://server/svn/имя_репозитория) и пароль с логином для доступа к нему. Используя эти данные можно получить код из хранилища командой

svn checkout путь_к_репозиторию локальная_директория

или аналогичной командой клиента с графическим интерфейсом. После этого в указанную директорию будет загружен код из репозитория. Если код уже был получен, то выполнять команду checkout не нужно, нужно просто обновить код:

svn update

Если в репозитории есть свежий код, он будет закачан. Внимание! Вот тут иногда бывают конфликты, но о них позже.

Добавление файлов в проект/Удаление из проекта

Если вы создали новый файл или директорию, надо сказать Subversion добавить это в проект, иначе система не сможет с этим работать. Для этого существует комманда:

svn add имя_файла_или_директории

Директория будет добавлена со всем содержимым, чтобы просто создать директорию выполните

svn mkdir имя_директории

Удаление:

svn delete имя_файла_или_директории

Если удаляется директория, то она будет помечена для удаления и удалена при комите.

Переименование, перемещение файлов

Никогда не удаляйте файл, с последующим добавлением его в репозиторий, для того чтобы его переименовать или переместить. Почему? Потому что в таком случае полностью будет утеряна история связанная с этим файлом. Для этих операций используйте:

svn move имя_исходного_файла имя_конечного_файла

Просмотр статуса

Посмотреть, какие файлы вы изменили можно коммандой

svn status

После выполнения будет выведен список файлов отличающихся от выкачанной ревизии. Крайне полезный для этой комманды ключик -u, он показывает какие файлы были обновлены в репозитории по отношении к взятой вами ревизии. Дело в том, что за время прошедшее с того момента как вы делали checkout или update, кто-то мог сохранить в репозиторий свои изменения. Вот их Subversion и покажет, если будете использовать ключ -u.

Кстати, если вдруг решите отменить изменения в каком либо файле, наберите:

svn revert имя_файла

Сохранение изменений

После того, как вы закончили вносить изменения в код, его нужно сохранить. Делается это коммандой

svn commit -m "комментарии к комиту"

Ключ -m можно опустить, в таком случае будут вызван текстовой редактор, где нужно будет ввести свои комментарии. Если при выходе из редактора файл не сохранить, комит сделан не будет.

Писать осмысленные комментарии крайне важно и для себя и для других. Это очень сильно поможет в будущем при просмотре репозитория. Графоманить тоже не стоит, вот пример нормальных комментариев: "Добавлена функция округления Round" или "Исправлен bug #2234".

Делать комиты нужно как можно чаще, для одной задачи один комит. Исправили баг — закомитили, не ждем пока накопится куча кода. Это убережет от массы проблем, например меньше риск сломать сборку или нарваться на конфликт версий.

Перед комитом всегда надо обновить код из репозитория, проверить собираемость, запустить юнит тесты. Внимание! Никогда не комитим неработающий код! Выйдет себе дороже.

Просмотр истории

Посмотреть, кто и что делал в репозитории можно командой

svn log

Можно посмотреть информацию по конкретному файлу:

svn log имя_файла

Если добавить ключ -r, будут показаны изменения между двумя ревизиями:

svn log -r младшая_ревизия:старшая_ревизия

Для ревизий есть псевдонимы, вот несколько основных:

HEAD — самая последняя ревизия

BASE — ревизия от которой сейчас файлы на локальной машине

PREV — просто предыдущая ревизия

Вот на этом этапе хорошо понимаешь, зачем давать осмысленные комментарии к комиту — вся разработка как на ладони.

Посмотреть отличия между двумя ревизиями можно с помощью комманды

svn diff -r младшая_ревизия:старшая_ревизия

Можно смотреть изменения только для конкретного файла, указав его имя. Тут мы и переходим к следующему разделу.

Просмотр изменений

Всегда можно посмотреть чем отличается файл одной ревизии от того же файла в другой ревизии. Это настолько удобно, что трудно переоценить. Бывает, что в процессе разработки что-то сломалось, вот тут и понимаешь всю ценность этой возможности.

Сказать SVN показать в каком месте файл отличается от более раннего файла можно коммандой

svn diff имя_файла -r младшая_ревизия:старшая_ревизия

Но конечно гораздо удобней воспользоваться специальными программами. Вот например как выглядит сравнение двух ревизий в WinMerge:

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

Конфликт — это на самом деле не страшно. Означает это то, что одновременно с вами над тем же самым кодом работал кто-то еще и изменения накладываются друг на друга. В этом случае программа говорит, что сама не знает, что нужно делать, поэтому делайте все сами. Что это означает? Это означает, что вам (если бы первым комитились вы, то сообветственно пришлось бы это делать другому) нужно разобраться какие изменения внести, а какие выбросить. Для этого первым делом смотрите файл с конфликтом. Subversion строки с конфликтами обозначает следующим образом:

<<<<<<< .mine
for (int j = 0; j != 10; ++j)
=======
for (int i = 0; i != 10; ++i)
>>>>>>> .r18

Здесь mine — это то, что сделали Вы, а r18 соответственно код из 18 ревизии который конфликтует с вашим. В приведенном примере все тривиально, кроме имени переменной отличий нет, поэтому вы можете самостоятельно внести правку (изменить имя переменной), сказать SVN коммандой

svn resolved имя_файла

что все в порядке и снова попробовать закомитить изменения.

Вероятно, что конфликт будет не совсем тривиальным. В таком случае смотрите по логу кто внес изменения

svn log -r номер_ревизии_с_конфликтом

и идете к этому человеку. Обьясняете, что ваш код конфликтует и вместе думаете как его слить, что-бы избежать конфликта.

Что еще?

Существует вероятность, что при работе с репозиторием произойдет сбой, например пропадет питание компьютера. В этом случае могут быть повреждены файлы SVN на рабочей машине. Для восстановления можно будет попробовать выполнить:

svn cleanup

Литература

Отличная книга по Subversion на официальном сайте