SVN и Git для начинающих

Subversion

Subversion — система управления версиями в свободной лицензии. Известна под сокращенным именем SVN. Разработка Subversion началась в 2000 году по инициативе и финансовой поддержке компании CollabNet Inc.

Основной целью проекта Subversion считается замена устаревший, на тот момент системы контроля версий CVS (Concurrent Versions System). Новый проект должен был сохранить всю функциональность CVS и избавиться от ряда его недостатков.

Официальный выпуск Subversion — 2004 год.

Git

Разработка Git началась в 2005 году, по инициативе разработчика Linux — Линуса Торвальдса.

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

Технические вопросы устройства

Две концепции, используемые для разделения файлов

Чтобы разделить файловое хранилище на множество пользователей можно использовать одну из двух известных схем разделения.

  1. Lock-Modify-Unlock — чтобы внести изменение, надо заблокировать файловое хранилище, выполнить изменение и, после этого, разблокировать (вернуть в общее пользование). Такая схема может работать в полностью автоматическом режиме, так как исключает возможные коллизии изменений, и используется в многопоточном программировании для защиты критических секций данных. В файловых репозиториях, такая схема не удобна, так как исключает возможность параллельной работы пользователей над изменением файлов.
  2. Copy-Modify-Merge — каждый из пользователей работает со своей копией данных, которая потом синхронизируется с состоянием центрального репозитория. Недостатком таких схем является необходимость ручного вмешательства в процесс синхронизации разных копий, если в них содержатся изменения одного и того же фрагмента данных.

Обе системы, Subversion и Git, используют вторую схему разделения данных (Copy-Modify-Merge), но делают это немного по-разному.

Больше:  Работа с SVN свойствами

Физическое представление репозитория

Subversion

SVN относится к типу централизованных систем, в отличии от Git и Mercurial, которые являются представителями класса распределенных систем. Централизованность означает работу схемы только при наличии централизованного хранилища данных.

Развертывание системы Subversion может опираться на две разные физические системы хранения данных репозитория. Исторически, первый вариант организации репозитория был основан на использовании СУБД Berkeley DB. Позже, была выполнена реализация на основе специального файлового хранилища данных (FSFS), поддерживаемое собственными программными библиотеками. Начиная с релиза 1.2 для новых хранилищ, по умолчанию, используется FSFS.

Реализацию на основе СУБД Berkley DB можно считать более капризной. Во-первых, ее настройка требует большего внимания администратора. Во-вторых, Berkley DB требовательна к выбору низлежащей файловой системы — она должна поддерживать блокировки.

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

Логическое представление репозитория

Репозиторий проекта может быть логически представлен двумерным массивом в котором вертикальным индексом является имя файла, а горизонтальным — номер ревизии — целое
число, растущее при каждой фиксации кода в хранилище. Каждая выборка из репозитория представляет собой «срез» файлов по номеру ревизии. Если номер ревизии не указывается
(обычно через опцию -r), то берется самый последний номер ревизии.

Примечание: картинка взята со страницы https://ru.wikipedia.org/wiki/Subversion

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

Больше:  Системы управления версиями git и svn

SVN vs Git. Здесь мы наблюдаем существенное различие в использовании, и, особенно,
администрировании систем SVN и Git. В Git, под каждый проект в любой директории
можно реализовать работу локального репозитория, чего, часто, для индивидуальной
работы, бывает достаточно. Централизованный репозиторий, при его необходимости,
так же организуется под каждый проект отдельно, позволяя для каждого проекта
построить свою политику прав доступа. Если быть более точным, то Git значительно
сосредоточен именно на средствах управления версиями и, при использовании
централизованных репозиториев, для тонкого разделения доступа к коду проекта
множества пользователей удобнее использовать дополнительные оберточные средства
администрирования Git. Cреди последних, известными являются gitolite и gitosys.

Различают понятия стержневых ревизий (peg revision) и оперативных ревизий (operative revision). Стержневая ревизия представляет собой номер ревизии предназначенный для уточнения файловых историй для оперативных ревизий по которым выполняются операции команд. Т.е. Команда может быть задана по диапазону оперативных ревизий в которых может быть коллизии файловых историй связанных с операциями копирования, перемещения и уничтожения файлов. Чтобы однозначно указать требуемую файловую историю необходимо указывать стержневую ревизию по правому краю диапазона оперативных ревизий, так как история файла однозначно отслеживается только в обратном направлении. При
отслеживании истории в прямом направлении можно столкнуться, например, с разветвлением, созданным при копировании файла. Работа пользователя с файлами проекта выполняется в рабочей копии репозитория, которая создается получением файлового снимка всего репозитория SVN или его части (через уточнение нужной поддиректории) с помощью операции svn checkout (по умолчанию будет передана последняя ревизия). Если пользователь хочет зафиксировать изменения в репозитории проекта, то он должен выполнить операцию svn commit. При каждой фиксации кода создается новая ревизия с большим номером.

Больше:  Правильный цикл работы с версиями SVN

Git

Основная суть организации репозитория Git в том, что он хранит файлы в виде файлов, а в качестве имени файла в репозитории используется значение хэш-функции SHA1, вычисленной по содержимому файла.

Таким образом, одинаковые файлы имеют одинаковое значение хеш-функции и хранятся один раз.

Одной из особенностей такого файлового хранения является то, что в Git не хранятся директории как таковые, а только в виде файловых путей. Следовательно, пустую директорию нельзя сохранить в репозитории Git.