digiwhite 14.09.2010 21:15
Переводы — Subversion vs. Git: выбираем правильную систему контроля версий с открытым исходным кодом.
ОригиналКак и все в мире открытого исходного кода, системы контроля версий (СКВ) появились по нескольким причинам. Дедушкой СКВ с открытым исходным кодом была CVS, инструмент, который де-факто являлся стандартом в индустрии разработки на протяжении нескольких лет, пока не пришли другие системы, такие как Subversion и, благодаря своим возможностям, сделали CVS почти что устаревшей.
В общем и целом все системы контроля версий подразделяются на две категории:
централизованные СКВ. Репозиторий является единственным и хранится на сервере;
распределенные СКВ. Каждый клиент хранит у себя полную копию репозитория локально.
CVS и Subversion - две наиболее популярные централизованные СКВ, в то время как Git, Mercurial, Bazaar и Monotone являются их распределенными аналогами.
Выбор СКВ, удовлетворяющей требованиям проекта зависит от нескольких вещей, включающих в себя следующее:
типы файлов, с которыми придется работать;
люди, которые будут работать с СКВ;
операционная система, которая будет использована.
Тем не менее, первый выбор, который вам предстоит сделать - это понять, использовать ли централизованную или же распределенную систему контроля версий, и этот выбор зависит от ваших предпочтений и соответствующего опыта по работе с СКВ. Учитывая, что Subversion и Git - наиболее популярные системы в своих категориях, в этой статье я выбрал их для противопоставления друг другу. У той и другой имеются различные преимущества. Чтобы помочь вам выбрать одну из них, я раскрою их основные отличия и затем расскажу о достоинствах и недостатках каждой.
Отличия между Subversion и Git
На данный момент Subversion является самой популярной централизованной системой контроля версий. В 2000 году компания CollabNet Inc. начала поиски разработчиков для создания замены для CVS, которая поддерживала бы ее основные концепции, но в то же время исправляла ее наиболее "яркие" проблемы. Через несколько месяцев была выпущена первая версия Subversion, и с тех пор она стала чрезвычайно популярна среди разработчиков.
Как было сказано выше, Subversion является централизованной СКВ. Пользователь может создать локальную копию репозиторя на своей машине (check out - в русском языке устоялся англицизм - чекаут) и после внесения изменений выполнить фиксацию изменений в репозитории (check in - англицизм - чекин) (записать изменения на сервер) на сервере. Как и в любой СКВ, вы можете сравнить две версии, создать ветку и выполнить ее слияние с основной веткой разработки, а так же разрешить конфликты там, где они возникнут.
В противоположность Subversion, Git была разработана с нуля как распределенная система контроля версий. Она предоставляет такое количество полностью идентичных копий всего кода, истории изменений и мета-информации, сколько имеется пользователей. Поэтому, даже если центральный репозиторий был утерян в результате отказа системы, все данные, за исключением нескольких последних изменений, которые не были зафиксированы, можно восстановить с любой клиентской машины. В таких централизованных СКВ, как Subversion, только центральный репозиторий может содержать полную историю изменений. Клиент должен иметь связь с сервером через сеть для получения истории по каждому необходимому файлу. Поэтому, если с центральным репозиторием случится беда, то придется обращаться к последним резервным копиям сервера.
Итак, самое большое отличие между Subversion и Git это то, что Subverion является централизованной СКВ и только основной репозиторий хранит полную историю изменений, в то время как все пользователи Git имеют у себя в наличии полную информацию об изменениях. Естественной реакцией в данном случае должно было бы стать желание дать несколько дополнительных очков Git, но данная особенность имеет и недостатки. С учетом того, если вы будете хранить проприетарный исходный код в Git, то вам следует задуматься о безопасности настолько, насколько это возможно. В распределенных системах чрезвычайно сложно обезопасить ваши данные от несанкционированного распространения, потому что существует множество копий этих данных.
При использовании Subversion все данные должны записываться на и читаться с центрального или основного сервера. Обеспечив безопасность этого сервера, вы гарантируете безопасность ваших данных. Для обеспечения же "отказоустойчивости" данных вы систематически можете делать резервные копии сервера репозитория Subverson.
Поддержка различных платформ: преимущество Subversion
Как я уже сказал ранее, один из факторов, который необходимо учитывать при выборе СКВ - это операционная система, под управлением которой вы хотите получить доступ к вашим данным. В то время, как Subversion отлично работает на всех операционных системах (имеется в виду Linux/Windows и Mac OS - прим. пер.), Git имеет определенные проблемы в работе под управлением Windows. В ОС Windows имеется существенная нехватка качественных приложений с графическим интерфейсом для доступа к репозиториям Git, поэтому использование этой СКВ все еще остается уделом пользователей Linux/UNIX и некоторых пользователей Mac. Но фактически, только Linux проекты, такие как ядро Linux, проект Fedora и Wine используют Git (на самом деле этих проектов гораздо больше, по ссылке http://en.wikipedia.org/wiki/Git_%28software%29 можно получить достаточно подробный список).
Простота использования в совокупности с пользовательским интерфейсом: преимущество Subversion
На данный момент Subversion имеет обширный диапазон инструментов с графическим интерфейсом пользователя в отличие от Git. Например, плагины Subversion доступны для большинства основных IDE на всех платформах, существует расширение для Windows Explorer и набор родных инструментов для Windows и Mac OS X.
Однако, если смотреть с другой стороны, Git, в первую очередь, это инструмент для работы через командную строку. В то время как некоторые разработчики наиболее комфортно чувствуют себя, используя командный интерпретатор, другие пользователи, особенно дизайнеры, боятся использовать Git, поскольку он не имеет графического интерфейса пользователя.
Работа с ветвями: преимущество Git
Одно из огромнейших преимуществ систем контроля версий - это возможность создавать ветви, отходящие от основной. В Git ветвь - это не пустое слово. Ветви используются очень часто, некоторые разработчики используют их несколько раз в день. Вы создаете ветвь для каждой новой фитчи или исправления ошибки, и после того, как вы сделаете задуманное, вы безболезненно выполняете слияние веток. В Subversion тоже легко создать ветку, однако в случае конфликта при слиянии вы окажетесь в неприятной ситуации. Вам придется вручную разрешать возникшие конфликты в измененных файлах.
Быстродействие и использование свободного места: преимущество Git
Когда приходит время сравнивать скорость обработки информации и место, занимаемое для хранения мета-информации СКВ, Git безоговорочно побеждает. Все из-за того, что в Git репозиторий целиком доступен пользователю, хранится локально и следующие действия выполняются локально без сетевых задержек:
просмотр истории файла;
выполнение операции просмотра изменений (diff);
получение другой версии файла;
cлияние ветвей;
фиксация изменений в репозитории.
Только операции клонирования удаленного репозитория(clone - прим. пер.) и слияния локального и удаленного репозитория(push) требуют соединения по сети. Сравните это с Subversion, где каждая операция требует наличия соединения с репозиторием.
Требования к свободному месту для Subversion для хранение рпозитория являются очень большими в сравнении с Git. Для примера возьмем проект Mozilla, который требует 12 Гб под репозиторий Subversion для хранения исходного кода с десятилетней историей. В репозитории Git тот же самый исходный код с историей требует 430 Мб - 30-и кратное уменьшение размера.
Причина такого гигантского отличия в способе хранения изменений в обеих системах. Git использует приблизительно по 100 байт данных в индексном файле для сохранения изменений, сделанных над файлом в репозитории, в то время как в репозитории Subversion хранится две версии каждого файла; одна версия - с которой пользователь работает в данный момент, и другая, скрытая в директории .svn/ - для выполнения таких операций, как получение статуса файла, получение изменений по отношении к текущему файлу и фиксация изменений.
Заключение
Если вы когда-либо совместно работали с другими людьми над проектом, то тогда вы отлично осведомлены о том, какое разочарование приносит использование разделяемых файлов. Передаете ли вы электронные сообщения как файлы кому-то другому или загружаете файлы на сервер, то очень часто вы проклинаете кого-нибудь из вашей команды, потому что он перезаписал сделанные вами изменения. Те строки кода, которые вы написали, пропали - преданы забвению. Самый простой способ избежать этой проблемы - это убедиться в том, что только один человек работает в данный момент времени с данным файлом. Кажется, что это просто, как сказать "А", однако это может стать изрядной проблемой, т.к. потребует ужесточения политики работы в команде. Время начать использовать систему контроля версий.
В этой статье я рассказал о некоторых ключевые отличиях между системами контроля версий Git и Subversion. Существуют еще и другие СКВ, которые вы возможно захотите рассмотреть, прежде чем выбрать какую-то из них. Если вы до сих пор еще не использовали подобную систему, то начните использовать одну из них прямо сейчас. Если вы не можете определиться с выбором, то я рекомендую вам начать с Subversion потому, что на пути к ее изучению лежит меньше трудностей.
Переведено инициативной группой переводчиков социальной сети welinux.ru
dicson 14.09.2010 21:24 #
+ 6 -
Подождем mercurial vs git. Там интереснее ))
Ну да, там что-то в стиле: одни у другого "воруют" интерфейс пользователя (систему команд), а другие у одних "ворют" фитчи :)
Выбрал гит.
Я могу работать с свн-репозиториями, а пользователи свн - не могут работать с гит-репами =)
Я могу работать с свн-репозиториями, а пользователи свн - не могут работать с гит-репами =)
за перевод спасибо=) но нашёл ошибки, под спойлером приведу их
надо
тут СКВ должно быть, по идее=)
надо
надо
надо
нужна запятая после Subversion
тут не нужна запятая
нужна запятая перед "сколько".
оба слова слитно должны быть
запятую надо переставить на одно слово вперёд, перед "потому"
нужна запятая после "сервера"
надо
нужно тире перед "это"
должно быть
ну, тут, думаю, итак видно=)
нужна запятая перед "сделанных"
"хранится"
нужно
CVS и Subversion две наиболее популярные централизованные СКВ
надо
CVS и Subversion - две наиболее популярные централизованные СКВ
Выбор КВС, удовлетворяющей
тут СКВ должно быть, по идее=)
предстоит сделать - это понять использовать ли централизованную
надо
предстоит сделать - это понять, использовать ли централизованную
систему контроля версий и этот выбор зависит от ваших предпочтений
надо
систему контроля версий, и этот выбор зависит от ваших предпочтений
Учитывая, что Subversion и Git наиболее популярные системы в своих категориях
надо
Учитывая, что Subversion и Git - наиболее популярные системы в своих категориях
Через несколько месяцев была выпущена первая версия Subversion и с тех пор она стала чрезвычайно популярна среди разработчиков.
нужна запятая после Subversion
после внесения изменений, выполнить фиксацию изменений
тут не нужна запятая
истории изменений и мета-информации сколько имеется пользователей.
нужна запятая перед "сколько".
на столько, на сколько
оба слова слитно должны быть
несанкционированного распространения потому, что существует множество копий этих данных.
запятую надо переставить на одно слово вперёд, перед "потому"
Обеспечив безопасность этого сервера вы гарантируете безопасность ваших данных.
нужна запятая после "сервера"
комфортно чувствуют себя используя командную интерпретатор,
надо
комфортно чувствуют себя, используя командный интерпретатор,
Одно из огромнейших преимуществ систем контроля версий это возможность создавать ветви,
нужно тире перед "это"
исправления ошибки и после того, как вы сделаете задуманное
должно быть
исправления ошибки, и после того, как вы сделаете задуманное
под хранение рпозитория
ну, тут, думаю, итак видно=)
для сохранения изменений сделанных над файлом в репозитории
нужна запятая перед "сделанных"
в репозитории Subversion храниться две версии каждого файла
"хранится"
одна версия с которой пользователь работает в данный момент и другая, скрытая в директории .svn/, для выполнения таких операций как получение статуса файла
нужно
одна версия - с которой пользователь работает в данный момент, и другая, скрытая в директории .svn/ - для выполнения таких операций, как получение статуса файла
Спасибо, исправлю :). А КВС - это командир воздушного судна :-D, увлечение авиацией неожиданно выпрыгнуло из под сознания :)
При использовании Subversion все данные должны записываться на (???) и читаться с центрального или основного сервера.
Что вас смутило? В русском языке это допустмая форма написания, чтобы избежать написания слова сервер дважды.
Ну, как-то слух режет =) возможно, если так:
Но если форма допустимая, то пускай, я только внимание обратил =)
При использовании Subversion все данные должны записываться на центральный или основной сервер, и читаться с него.
Но если форма допустимая, то пускай, я только внимание обратил =)
Пробовал mercurial, bazaar (CVS от Canonical) и Git. Выбрал последний. Даже не знаю почему :)
А я когда-то выбрал Mercurial. Тогда был еще под виндой, и там, с git`ом были как раз трудности.
Я когда-то перелез с subversion на git и теперь системы контроля версий не замечаю. Что мне и нужно. А c subversion все время было ощущение, что как-то не так.
Как я тебя понимаю! Точно такая же ситуация, только вместо git - mercurial.
На эту тему мне понравилось выступление Линуса Торвальдса в google.
http://www.youtube.com/watch?v=4XpnKHJAok8
http://www.youtube.com/watch?v=4XpnKHJAok8
"Время голосования за этот комментарий истекло", так что просто большое спасибо - слушаю с большим удовольствием :)
А можете рассказать, чем именно для вас Bazaar оказался удобней/лучше Git?
По теме поста -- в основном использую Mercurial и Git, и иногда путаюсь в командах. Надо все-таки наверное выбрать что-то одно.
SVN в последнее время использую только для получения чужих исходников .
По теме поста -- в основном использую Mercurial и Git, и иногда путаюсь в командах. Надо все-таки наверное выбрать что-то одно.
SVN в последнее время использую только для получения чужих исходников .
За давностью уже всех причин не помню, но попробую восстановить.
Во-первых, у Bazaar номера версий "человеческие" - просто номера. У Git какие-то длинные числа. Во-вторых, я тогда планировал использовать СКВ и на рабочем ноутбуке с виндой - Bazaar вроде как лучше приспособлен. В третьих, я провёл сравнительные тесты с удалением и добавлением файлов в проект - в Bazaar пара команд bzr add / bzr commit гарантированно учитывала все изменения, а в Git приходилось ещё что-то дополнительное делать.
Во-первых, у Bazaar номера версий "человеческие" - просто номера. У Git какие-то длинные числа. Во-вторых, я тогда планировал использовать СКВ и на рабочем ноутбуке с виндой - Bazaar вроде как лучше приспособлен. В третьих, я провёл сравнительные тесты с удалением и добавлением файлов в проект - в Bazaar пара команд bzr add / bzr commit гарантированно учитывала все изменения, а в Git приходилось ещё что-то дополнительное делать.
О, человечные номера коммитов это удобно. Уже ради этого надо бы попробовать использовать эту DCVS. Мне в Git в принципе только этого и не хватает, хэши эти иногда просто бесят. В Mercurilal простая нумерация есть, но hg log дает неудобный вывод "снизу вверх" (чтобы посмотреть самые последние коммиты, надо прокрутить консолльный вывод).
в Bazaar пара команд bzr add / bzr commit гарантированно учитывала все изменения, а в Git приходилось ещё что-то дополнительное делать.
git commit -a у меня сразу учитывал все изменения, сделанные после предыдущего коммита, и руками добавлять файлы через git add не приходилось.
git commit -a у меня сразу учитывал все изменения, сделанные после предыдущего коммита, и руками добавлять файлы через git add не приходилось.
Обманывать нехорошо - -a комитит только то, что есть в индексе. Т.е. без принудительного добавления в коммит попадут только измененные файлы, а новые будут пропущены.
В гите большая часть "магии" кроется в ключах.
bzr add / bzr commit = git add -A / git commit =)
У каждой команды over 9000 ключей =)
bzr add / bzr commit = git add -A / git commit =)
У каждой команды over 9000 ключей =)
Кстати, а как он расставляет номера при мерже?
Например, в "центральном" хранилище лежит ревизия 1. Я и ты склонировали ее. Я сделал 4 коммита и ты сделал 4 коммита - итого у нас HEAD = 5. Я сделал пуш, ты пулл, ты пуш, я пулл. Допустим, что все было красиво и никаких конфликтов при мерже не возникло. Какие номера коммитов будут на сервере, у меня и у тебя?
Например, в "центральном" хранилище лежит ревизия 1. Я и ты склонировали ее. Я сделал 4 коммита и ты сделал 4 коммита - итого у нас HEAD = 5. Я сделал пуш, ты пулл, ты пуш, я пулл. Допустим, что все было красиво и никаких конфликтов при мерже не возникло. Какие номера коммитов будут на сервере, у меня и у тебя?
Если честно, лично я пока использую bzr "в одно лицо". Так что не могу квалифицированно ответить.
Bazaar поддерживает большее количество серверов: можно писать репу прямо на ftp. У Bazaar шикарный gui: qbzr + bzr-explorer
Однако последнее для пользователей linux'а далеко не самый важный критерий.
Однако последнее для пользователей linux'а далеко не самый важный критерий.