Мнение о различных VCS

Тут описывается лишь моё мнение, которое может иметь достаточно посредственное отношение к реальности.

Однако, оно может дать некоторую полезную информацию для тех, кто только знакомится с системами контроля версий.

Рассматриваются SVN, Git, Mercurial, Perforce.

Глоссарий находится в конце статьи.

Subversion (SVN)

Самая знаменитая и распространённая VCS. Один из случаев, когда “самый знаменитый” не значит “самый лучший”.

Я начинал с неё. И сейчас часто приходится с ней работать.

SVN — централизованная система контроля версий. Это значит, что основная информация хранится на сервере, а пользователи получают лишь “представления” для работы с ней.

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

Структура

Репозиторий можно рассмотреть как двумерное пространство, где одной осью является файловая система, а другой – время.

Набор изменений – это снимок проекта на определённый момент времени. Созданные наборы изменений не могут быть изменены или удалены.

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

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

Плюсы

  • проста в освоении;
  • легко развернуть как на сервере так и на локальной машине;
  • поддерживается в большинстве IDE и системах отслеживания ошибок;
  • любое внесённое изменение будет сохранено навсегда;
  • возможно хранить несколько проектов в одном репозитории.

Минусы

  • если изучать его по мануалам, то пропадает (или даже не возникает вообще) желание использовать ветвление;
  • при фиксации ошибочного изменения оно сразу же попадает на сервер и не может быть удалено (только отменено следующим изменением);
  • сервер должен быть доступен в режиме 24/7, иначе работа с контролем версий превращается из удовольствия в настоящий Ад.

Git

Моя любимая VCS. В своих проектах стараюсь использовать только её.

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

Структура

Все правки (наборы изменений) хранятся в виде графа.

Каждый узел графа представляет собой определённый набор изменений. Идентификатором узла является его хеш-сумма.

Ветка — это по сути ссылка на определённую правку. При записи новых изменений в ветку, она смещается на последний новый набор изменений. Таким образом, вы будто бы наращиваете ветки, добавляя на них новые правки.

Часть веток может быть удалена (безвозвратно) или быть перенесена на другие ветки графа.

У пользователя на компьютере хранятся все правки из репозитория (либо только те ветки на которых основана его работа). Другими словами, если вы разрабатываете распределённый проект и сервер со всеми бекапами был потерян, то восстановить репозиторий на сервере можно будет взяв правки у пары-тройки пользователей.

Плюсы

  • даёт полную свободу работы с версиями;
  • нет необходимости постоянно иметь соединение с сервером;
  • можно иметь несколько серверов или не иметь ни одного;
  • поддерживается в большинстве IDE и системах отслеживания ошибок;
  • можно посылать на сервер только проверенные изменения, а тестовые правки оставлять на своей машине;
  • имеет возможность ограниченно работать с репозиториями SVN.

Минусы

  • сложнее освоить (особенно после централизованных VCS);
  • при первом подключении к серверу нужно скачать всю историю изменений нужной ветки (размер может исчисляться гигабайтами);
  • можно создать слишком запутанную структуру правок в репозитории;
  • если не придерживаться определённых простых правил, можно испортить настроение своим коллегам по распределённой разработке.

Mercurial (Hg)

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

Mercurial схожа с Git своей распределённой структурой, однако имеет более строгий подход к ветвлению нежели в Git.

Это одновременно и плюс и минус. Плюс — сложнее создать запутанную структуру в репозитории, минус — нет возможности перемещать правки и делать некоторые другие вещи за которые многие так любят Git.

Mercurial немного хуже поддерживается разработчиками IDE, а так же имеет более скромный набор графических оболочек в отличие от Git и SVN.

Perforce (P4)

Perforce похожа на SVN своей централизованностью, структурой репозитория и ветвлением, но есть и заметные отличия.

Если в SVN, при отсутствии соединения с сервером, работа становится адом, то используя Perforce без сервера работать просто невозможно. Вся информация о версиях хранится на сервере, а пользователь всегда остаётся один на один со своей рабочей копией.

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

Есть ещё несколько проблем, которые мешают работать первое время. Например, чтобы внести изменение в какой-нибудь файл, нужно попросить разрешения у Perforce, иначе он начнёт вести себя очень странно. Иногда приходится фиксировать пустые правки. То есть не “можно фиксировать пустые правки”, а “если не зафиксировать пустой список изменений, то Perforce не даст спокойно работать”. К этому надо привыкнуть.

У меня сложилось стойкое ощущение, что Perforce разрабатывали ориентируясь не на программистов, которые будут с ним работать, а на менеджеров, которые боятся что программисты что-нибудь обязательно утащат.

Плюсы

  • Тотальный контроль над всем;
  • Идущая от разработчиков графическая оболочка;
  • Возможность удобно комбинировать работу над несколькими модулями;
  • Удобная работа со списками изменений.

Минусы

  • Трудно заставить себя привыкнуть к тому, что инструмент диктует тебе как работать, а не наоборот;
  • Когда теряется связь с сервером, прекращается продуктивная работа.

Коротко о главном

Системы контроля версий можно разделить на два лагеря: централизованные и распределённые.

SVN и Perforce относятся к централизованным, Git и Mercurial — к распределённым.

Централизованные системы контроля версий дают больший контроль, а распределённые — большую свободу в работе с версиями.

Использованные обозначения

VCS (Version Control System) — система контроля версий. Не путать с CVS (Concurrent Versions System) — предшественником SVN.

Правка или набор изменений — зафиксированные на определённый момент изменения в одном или нескольких файлах. В VCS набор изменений рассматривается как атомарный объект. Нельзя редактировать созданные наборы изменений, только удалять и создавать новые.

Репозиторий — хранилище системы контроля версий. В репозиториях хранятся наборы изменений и связанная с ними информация. В централизованных VCS такое хранилище одно, однако, иногда оно может иметь зеркала. В распределённых системах контроля версиями, каждая рабочая копия имеет свой репозиторий; для одной рабочей копии может быть несколько удалённых репозиториев, которые могут хранить различные наборы изменений.

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

Фиксация набора изменений — процесс создания новой правки из изменений рабочей копии.

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

Слияние — процесс объединения изменений из нескольких веток.

Поделиться

Leave a Reply