Словарь
branch
Ветка — направление разработки, независимое от других. Ветка представляет собой копию документа, в которую можно вносить свои изменения, не влияющие на другие ветки. Документы в разных ветках имеют одинаковую историю до точки ветвления и разные — после неё.
check-in, commit, submit
Копирование изменений, сделанных в рабочей копии, в хранилище документов. При этом создаётся новая версия.
check-out
Извлечение документа из хранилища и создание рабочей копии.
conflict
Конфликт возникает, когда изменения вносятся двумя разными сторонами в один документ или в одно место внутри одного и того же документа. Поскольку программа может быть недостаточно разумна для того чтобы определить, какое изменение является «корректным», пользователю нужно самому разрешить конфликт (resolve).
merge, integration
Объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую.
repository
Хранилище документов — место, где хранятся все документы вместе с историей их изменения и другой служебной информацией.
revision
Версия документа. Системы управления версиями различают версии по номерам, которые назначаются автоматически.
tag, label
Метка, которую можно присвоить определённой версии документа. У разных документов одинаковая метка может соответствовать разным номерам версий.
update, sync
Копирование изменений, произведённых над хранилищем документов, в рабочую копию.
working copy
Рабочая (локальная) копия документов.
Распределённые системы
Отличие таких систем - отсутствие центрального репозитория, к которому обращаются клиентские программы; репозиториев может быть много и между ними существует возможность синхронизации. Такой механизм работы даёт больше свободы разработчику, вместо получения рабочей копии и её отправки обратно в центральный репозиторий разработчик может получить репозиторий в своё полное владение - вносить изменения на своё усмотрение и только отдельные изменения синхронизировать с основным репозиторием.
Отдельные распределённые системы, как Bazaar-NG или Darcs упрощают механизм копирования репозиториев по максимуму. Чтобы сделать публичную копию репозитория достаточно скопировать все файлы исходного репозитория (включая разумеется служебные файлы относящиеся к VCS, которые хранятся обычно в специальной поддиректории) и выложить в любое доступное по протоколу http место - хоть на любой бесплатный хостинг; с помощью клиентского п/о с новым репозиторием можно будет работать как с исходным. Правда для доступа на запись в него придётся потратить больше усилий - предоставить доступ по ssh (в случае Darcs) или ftp (в случае Bazaar-NG). Особенно интересна эта модель для проектов свободного п/о, где часто разработка ведётся стихийно, без чётких сроков и планов, могут меняться лидеры проекта и имеющиеся в наличии ресурсы. Лёгкость создания копии репозитория в этом случае повышает надёжность в хранении кода - потеря "центрального" ресурса или уход лидера облегчит продолжение проекта, если остались другие заинтересованные разработчики, имеющие собственные копии репозиториев - одно дело текущий срез данных, другое наличие репозитория с полной историей изменений.
Инфа из википедии:
Darcs — система управления версиями с широкими возможностями, может быть использована для замены CVS. Darcs написана на языке Haskell, и может быть использована в GNU/Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD и Microsoft Windows. Darcs включает CGI-скрипт для просмотра репозиториев через web.
В противоположность CVS и Subversion, но подобно Arch и Monotone, Darcs является «распределённой» системой управления версиями.
Про Базар ничего более не нашел
Возражение, которое нередко выдвигают противники такой модели - лёгкость установки своего репозитория стимулирует форки проектов.
Форк (англ. fork — вилка) — процесс расщепления программного проекта (обычно свободного) на два отдельных проекта (ветки). При этом каждая из веток развивается независимо от другой, разными авторами. В одной ветке могут быть реализованы возможности, отсутствующие в другой, в таком случае обе ветки могут потерять совместимость между собой.
На мой взгляд это некорректное утверждение, поскольку форки стимулирует сама публичная доступность исходного кода. Если кому-то хочется сделать свой вариант программы, то наличие или отсутствие истории её измененей врядли его остановит. Если уж вы ведёте открытый проект и код публично доступен под одной из свободных лицензий - будьте готовы к тому, что кто-то попробует сделать похожий проект на базе вашего кода. Но если это не противоречит условиям лицензии и сделано с соблюдением авторские прав, то какие собственно претензии? Я полагаю, распределённые хранилища кода напротив, стимулируют участие в разработке основного проекта - конечно кому-то проще внести изменения и предоставить их как отдельную ветвь разработки, но при устойчивом статусе проекта более вероятно эти изменения захотят перенести в основную ветвь, поскольку там они будут более востребованы и популярны. Здесь и проявляются преимущества распределённых систем: свобода в изменении кода в своём репозитории и создании своих локальных версий, лёгкость синхронизации своих изменений с другими разработчиками и основными репозиториями проекта.
Ещё одна важная особенность, которая чаще встречается в распределённых системах (хотя нет препятствий для её реализации и в централизованной модели) - работа в офлайне. Вы вносите изменения и "отправляете" их в репозиторий находясь без подключения к сети - на самом деле система складывает их куда-нибудь на диске, а при наличии доступа в сеть - отправляет все отложенные изменения в репозиторий. Реализация здесь отличается для разных систем. Часть распределённых систем разделяют сервер и клиента - так например сделано в Codeville. Там отложенные изменения сохраняются на клиентской стороне (хотя по идее клиент и сервер могут быть на одной машине). А скажем в упомянутой выше Darcs, где любая копия сама себе репозиторий, такой механизм вовсе не требуется, поскольку вы всегда вносите изменения локально, а при наличии доступа в сеть переносите изменения из одного репозитория в другой. В любом случае, возможность такой офлайновой работы есть очень полезное свойство VCS. Не требуется оно только если все разработчики сидят в одном офисе, имеют постоянное подключение к сети и предпочитают вне офиса в код не лазить.
Значит ли вышесказанное, что распределённые системы предназначены исключительно для стихийных opensource-проектов, в то время как централизованную модель следует использовать в корпоративных разработках? Конечно, нет. В зависимости от принятой организации работ в фирменных разработках вполне применима распределённая модель - например если программисты работают дистанционно, через интернет или имеют привычку работать в разных офисах, дома и т.п. Распределённый репозиторий, который легко "унести" на ноутбуке даёт разработчику больше свободы и при этом сохраняет возможность содержать один "главный" репозиторий, куда в итоге должны стекаться все разработки.
Для исторической справки. Первой распределённой системой была TeamWare - разработка Sun Microsystems, использовавшаяся большей частью для внутренних проектов фирмы. Тот же разработчик, что проектировал TeamWare позже создал BitKeeper - другую рапспределённую систему под проприетарной лицензией, долгое время использовавшуюся командой разработчиков ядра GNU Linux.
Что такое проприетарный. Этим термином принято называть программы, распространяемые не в виде исходного текста, а уже в откомпилированном бинарном формате, который может прочесть компьютер и не может прочесть человек
Первая свободная реализация распределённой VCS - GNU Arch. Основная критика в адрес Arch - сложность в установке и использовании (команда tla, с помощью которой управляется Arch предлагает слишком уж много параметров и опций, не отличающихся стройностью логики, да ещё странные соглашения по именам файлов). Это послужило появлению позже альтернатив Arch, первыми из которых стали ArX и Bazaar.
Можно обратить своё внимание на системы изначально проектировавшиеся, чтобы быть распределёнными. К тому же они как правило очень просты в установке (к примеру Darcs под Linux есть в статической сборке подходящей под любой дистрибутив - в виде одного файла, который достаточно скопировать к себе на машину получив клиент и сервер в одном флаконе). На мой взгляд наиболее доработанными по функционалу являются Bazaar-NG, Darcs, Mercurial, Monotone. А может быть в итоге вы решите, что централизованная модель вас устраивает больше и возможностей Subversion или другой централизованной системы вам достаточно.
Еще
Git — распределённая система контроля версий файлов и совместной работы. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, а сегодня поддерживается Джунио Хамано (Junio C. Hamano).
Примерами проектов, использующих Git на сегодняшний день, являются Linux Kernel, Cairo, GNU Core Utilities, Mesa 3D, Wine, многие проекты X.org, XMMS2, Beryl, One Laptop Per Child (OLPC), GNU LilyPond, и ELinks и некоторые дистрибутивы Linux (см. ниже).
Программа является свободной и выпущена под лицензией GNU версии 2.
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированыне системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git. А StGit использует Git для управления коллекцией патчей.
Система имеет ряд пользовательских интерфейсов: например, gitk и git-gui распространяются с самим Git.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, SSH, или HTTP сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. HTTP метод доступа, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использование существующих конфигураций сетевых фильтров.
Mercurial — распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве Python-расширений на C. Репозитории Mercurial управляются при помощи утилиты командной строки hg.
Наряду с традиционными возможностями систем контроля версий, Mercurial поддерживает полностью децентрализованную работу (отсутствует понятие основного хранилища кода), ветвление (возможно вести несколько веток одного проекта и копировать изменения между ветками), слияние репозиториев (чем и достигается «распределённость» работы). Поддерживается обмен данными между репозиториями через HTTP/HTTPS, SSH[1] и вручную при помощи упакованных наборов изменений.
Mercurial использует SHA1-хеши для идентификации ревизий и позволяет присваивать отдельным ревизиям индивидуальные метки.
Утилита hg обладает компактным интерфейсом, и Mercurial считается простой в освоении системой.
Помимо юниксоподобных операционных систем (включая MacOS X), Mercurial может работать и под Windows.
Дополнительные средства
В комплекте с Mercurial поставляются CGI-сценарии для предоставления веб-интерфейса к репозиториям[1].
Ряд сред разработки имеет возможности для работы с Mercurial, например Eclipse [2], PIDA[3], NetBeans[4]. Возможна работа с Mercurial из Emacs c помощью поставляемого вместе с Mercurial пакета mercurial.el или других расширений[5].
Экспериментальная поддержка Mercurial есть в системе Trac[6].
При помощи утилиты Tailor [7] поддерживается конвертирование[8] репозиториев других систем контроля версий, включая CVS, Subversion, Git, Darcs, GNU Arch, Bazaar-NG.
Microsoft Visual SourceSafe (Visual SourceSafe, VSS) — программный продукт компании Майкрософт, файл-серверная система управления версиями, предназначенная для небольших команд разработчиков. VSS позволяет хранить в общем хранилище файлы, разделяемые несколькими пользователями, для каждого файла хранится история версий.
VSS входит в состав пакета Microsoft Visual Studio и интегрирован с продуктами этого пакета. Доступен только для платформы Windows. Версию для Unix поддерживает компания MainSoft.
В ноябре 2005 года вышла обновлённая версия продукта — Visual SourceSafe 2005, обещающая повышенную стабильность и производительность, улучшенный механизм слияния для XML-файлов и файлов в Юникоде, а также работу через HTTP.
Visual SourceSafe нацелен на индивидуальных разработчиков либо небольшие команды разработчиков. Там где VSS недостаточно, ему на замену предлагается новый продукт Майкрософт — Visual Studio Team Foundation Server, входящий в состав Visual Studio Team System.
Perforce — коммерческая система управления версиями. Разработана компанией Perforce Software, Inc., основанной в 1995. Система построена по клиент-серверной архитектуре. Perforce сервер может одновременно иметь несколько репозиториев, называемые "депо" (англ. depot).
Сервер Perforce может быть установлена на операционные системы Unix, Mac OS X, Microsoft Windows.
Клиент предоставлят графический интерфейс и широкий набор утилит для работы из командной строки. Клиентская часть реализована для широкого набора операционных систем. Так же разработан большой набор плагинов, позволяющих интегрироваться с широким кругом сред разработки программного обеспечения и приложений других разработчиков: XCode, Autodesk 3D Studio Max, Alias Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs. Помимо этого система предоставляет множество других возможностей - различного вида извещения (notification), создание и обслуживание ветвей проекта (branching), с мощной системой слияний веток (merging), точки отката в базе данных (checkpoints), и взаимодействие с системами отслеживания дефектов (bug tracking).
В настоящее время насчитывается более 200 000 пользователей Preforce в 3 900 компаниях [1]. Например такие известные компании как Google и Microsoft, широко используют Perforce в своих инженерных процессах.
Rational ClearCase — система управления версиями разрабатываемая подразделением Rational Software компании IBM.
ClearCase была разработана компанией Atria Software и выпущена в 1992 году сначала для Unix, а позже и для Windows. Некоторые сотрудники Atria принимали участие в работе над более ранней системой DSSE (Domain Software Engineering Environment) в компании Apollo Computer. Позднее в результате слияния Atria с Pure Software образовалась компания PureAtria, которая затем объединилась с Rational Software, которая в свою очередь была куплена IBM. IBM продолжила разработку и продвижение на рынке системы ClearCase, которая широко используется компаниями производящими программное обеспечение.
DSEE
В DSEE были предложены многие концепции используемые сейчас в ClearCase. Файловая система Apollo Domain позволяла специальной управляющей программе вмешиваться в процесс доступа к файлам и DSEE стала использовать эту возможность для незаметного создания копии текущей версии каждого отдельного открытого файла.