Для домашних проектов, Mercurial или Git (или другие DVCS) предоставляют больше преимуществ перед Subversion?

Ответ 1

Взгляните на часть управления версиями для одного разработчика в ответе на вопрос Разница между GIT и CVS" в StackOverflow. Некоторые из этих проблем по-прежнему применяются также к Subversion в сравнении с GIT (или другим распределенным VCS: Mercurial, Bazaar или менее известным: Monotone, Darcs), даже если Subversion - это улучшение по сравнению с CVS.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я использую GIT (поэтому я предвзятый) и знаю Subversion только из документации (и других ресурсов), никогда не используя ее самостоятельно. Возможно, я ошибаюсь в возможностях Subversion.

Ниже приведен список различий между GIT над Subversion для одного разработчика на одной машине (отдельная учетная запись):

• Настройка хранилища. GIT хранит репозиторий в каталоге .git в верхней директории вашего проекта. Запуск нового проекта из неверсифицированного дерева файлов так же просто, как сделать "git init" в верхней директории вашего проекта (а затем, конечно, "git add." ), Чтобы добавить файлы и, например, "git commit -m 'Первоначальная фиксация' 'для создания первого коммита).

  В Subversion (в любой централизованной системе контроля версий) вам необходимо настроить центральный репозиторий (если вы этого не сделали раньше), используя "svnadmin create" (ну, вам нужно сделать это только один раз). Затем вам нужно импортировать файлы в Subversion, используя "svn import" (или "svn add" )... Но обратите внимание, что после завершения импорта исходное дерево не преобразуется в рабочую копию. Чтобы начать работать, вам все равно нужно "svn checkout" создать новую рабочую копию дерева.

• Метаданные репозитория и репозитория. GIT хранит как репозиторий (т.е. информацию об изменениях и ветких и т.д.), так и метаданные репозитория (например, ваша личность, список игнорируемых файлов, какая ветка в настоящее время проверяется) в каталоге .git в верхнем каталоге ваших проектов.

  Subversion хранит репозиторий в отдельной области, которую вы должны поставить для этой цели, и сохраняет метаданные репозитория (например, где центральный репозиторий, идентификатор, используемый для обращения в центральный репозиторий, и я также думаю, что такие свойства, как svn:ignore), хранятся в .svn в каталоге каждого каталога вашего проекта. (Обратите внимание, что Subversion хранит чистую копию вашего заказа, чтобы иметь "svn status" и "svn diff" )

• Именование версий/номеров версий. Subversion использует глобальные идентификаторы ревизий в виде одной версии с указанием номера, поэтому вы можете, например, обратиться к r344, редакция 344). Subversion также поддерживает несколько символических спецификаций пересмотра: HEAD, BASE, COMITTED, PREV.

  В GIT каждая версия проекта (каждая фиксация) имеет свое уникальное имя, заданное 40 hexdigits SHA-1 id; Обычно для идентификации фиксации достаточно первых 7-8 символов (вы не можете использовать простую схему нумерации для версий в системе управления распределенной версией, для которой требуется центральный авторитет нумерации). Но GIT предлагает также другие типы спецификаций ревизий, например HEAD^ означает родительский элемент текущей фиксации, master~5 означает обратно 5 предков назад (в прямой строке первого родителя) из верхней фиксации в ветки "ведущий", v1.6.3-rc2 может означать ревизию с тегами v1.6.3-rc2.

  См. также Множество разных спецификаторов ревизий в блоге Элайджа Ньюрена.

• Легкое разветвление и слияние. В GIT создание и объединение ветвей очень просто; GIT запоминает всю необходимую информацию сам по себе (поэтому объединение ветки происходит так же, как "git merge branchname" )... это должно было быть, потому что распределенное развитие, естественно, приводит к нескольким ветвям. GIT использует эвристическое определение переименования на основе сходства, поэтому при слиянии оно может иметь дело с случаем, когда одна сторона переименовала файл (и другие подобные случаи, связанные с переименованием). Это означает, что вы можете использовать рабочий процесс ветвей тем, т.е. Создать отдельную функцию в нескольких шагах в отдельной ветки функций.

  Филиалы имеют необычную реализацию в Subversion; они обрабатываются соглашением об именах: ветка представляет собой комбинацию ревизий в глобальном репозитории, которые существуют в определенном пространстве имен. Создание новой ветки осуществляется путем копирования существующего набора файлов из одного пространства имен в другое, записанного как сама ревизия. Subversion упростил создание новой ветки... но до версии 1.5 вам пришлось использовать дополнительные инструменты, такие как SVK или svnmerge, чтобы они могли легко сливаться. Subversion 1.5 вводит свойство svn:mergeinfo, но даже тогда слияние немного сложнее, чем в Git; также вам нужно использовать дополнительные опции для показа и использования информации отслеживания слияния в таких инструментах, как "svn log" и "svn wame". Я слышал, что он не работает корректно в более сложных ситуациях (criss-cross merge) и не может в настоящее время переименовывать (в этом случае есть даже вероятность молчаливой коррупции). См. Также (например) этот пост в GIT списке рассылки Дмитрия Потапова, объясняя предполагаемый прецедент для svn:mergeinfo и его (текущих) ограничений.

• Пометка. В тегах GIT неизменяемый, могут иметь связанный с ними комментарий и могут быть подписаны с использованием подписи PGP/GPG (и проверены), Они создаются с использованием тега git. Вы можете ссылаться на ревизию с использованием имени тега.

  В тегах Subversion используется такое же пространство имен типа path_info , что и ветки (рекомендуемое соглашение svnroot/project/tags/tagname), и они не защищены от изменения. Они создаются с использованием "svn copy". Они могут иметь комментарий, связанный с [фиксацией, создающей тег].

• Расширение ключевых слов. GIT предлагает очень, очень ограниченный набор ключевых слов по сравнению с Subversion (по умолчанию). Это происходит из-за двух фактов: изменения в GIT для каждого репозитория, а не для файла, а GIT избегает модификации файлов, которые не менялись при переключении на другую ветвь или переименование в другую точку истории. Если вы хотите вставить номер версии с помощью Git, вы должны сделать это, используя свою систему сборки, например. следуя exaple GIT -VERSION-GEN script в источниках ядра Linux и в источниках GIT. Существует также 'ident' gitattribute, который позволяет развернуть ключевое слово $Id $до идентификатора SHA-1 содержимого файла (не идентификатор коммита).

  Оба GIT и Subversion делают расширение ключевого слова только по запросу.

• Двоичные файлы. Оба GIT и Subversion правильно обрабатывают двоичные файлы. GIT обнаружение двоичного файла с использованием аналогичного алгоритма, используемого, например, GNU diff, если только не переопределяется на основе каждого маршрута с использованием gitattributes. Subversion делает это несколько иначе, обнаруживая тип файла во время добавления файла и устанавливая свойство svn:mime-type, которое вы затем можете изменить. Оба GIT и Subversion могут выполнять преобразование символов конца строки по запросу; GIT дополнительно имеет опцию core.safecrlf config, которая предупреждает и предотвращает необратимое изменение (все CR для всех CRLF обратимы, смешанные CR и CRLF не обратимы).

• Игнорирование файлов. GIT сохраняет шаблоны игнорирования с использованием файла in-tree .gitignore, который может быть установлен под управлением версиями и распределен; он обычно содержит шаблоны для продуктов сборки и других сгенерированных файлов и в файле .git/info/excludes, который обычно содержит шаблоны игнорирования, специфичные для пользователя или системы, например. игнорировать pattersn для файлов резервных копий вашего редактора. GIT шаблоны применяются рекурсивно, если только patter не содержит разделитель каталога, то есть символ косой черты '/', тогда он привязан к каталогу .gitignore file; в верхний каталог для .git/info/excludes. (Существует также переменная конфигурации core.excludesfile, эта переменная может существовать в конфигурационном файле для пользователя ~/.gitconfig и указывать на файл игнорирования каждого пользователя).

  Subversion использует опцию конфигурации global-ignores (которая обычно применяется к определенному компьютеру или конкретному пользователю компьютера) и свойство "svn:ignore" в каталогах с версией SVN. Однако, в отличие от опции global-ignores (и в .gitignore), шаблоны, найденные в свойстве "svn:ignore", применяются только к каталогу, в котором это свойство задано, а не к любому из его подкаталогов. Кроме того, Subversion не распознает использование префикса ! для шаблона как механизма исключения.

• Изменение коммитов.распределенный VCS, такой как публикация публикации GIT, не зависит от создания коммита, можно изменить (отредактировать, переписать) неопубликованную часть истории без неудобства другим пользователям. В частности, если вы заметили опечатку (или другую ошибку) в сообщении фиксации или ошибку в фиксации, вы можете просто использовать "git commit -amend". (Примечание: технически это повторное создание фиксации, а не изменение существующего фиксации, измененный фиксатор имеет другой идентификатор).

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

• Инструменты. С одной стороны GIT предлагает более богатый набор команд. Одним из наиболее важных является "git bisect", который можно использовать для обнаружения фиксации (ревизии), которая ввела ошибку; если ваши коммиты небольшие и автономные, должно быть довольно легко обнаружить, где ошибка.

  С другой стороны, Subversion потому, что существует дольше, возможно, имеет более широкий набор сторонних инструментов и поддержку Subversion в инструментах, чем Git. Или, по крайней мере, более зрелые. Особенно в MS Windows.

И есть еще одна проблема, которая может быть очень важна позже:

• Публикация репозитория. Если (когда?) в какой-то момент вы захотите поделиться своим репозиторием, превратив его из проекта с одним человеком, разработанного на одном домашнем компьютере, чему-то другому способствовать, с GIT так же просто, как создание пустого репозитория на сервере или на одном из существующих сайтов GIT хостинга/хостинга программного обеспечения с поддержкой GIT (например http://repo.or.cz, GitHub, Gitorious, InDefero; больше - также для других DVCS - указаны в который отвечает), а затем выкладывая проект в этот публичный репозиторий.

  Я думаю, что это сложнее с Subversion, если вы не начинаете с сайта хостинга с поддержкой Subversion (например, SourceForge) с самого начала, если только вы не хотите сохранять существующую историю изменений. С другой стороны, например, в Google Code предлагается использовать инструмент svnsync (часть стандартного дистрибутива Subversion), как описано в Google Products > Проект Хостинг (фронт Освобождения Данных).

Посмотрите также на http://whygitisbetterthanx.com/ сайт.

Ответ 2

Одно очевидное преимущество: вы можете развиваться, когда находитесь далеко от сервера. Например, у вас может быть ноутбук со своим локальным репозиторием git и нажмите на свой сервер (или github). Теперь предположим, что вы отправились куда-то без подключения к интернету... в Subversion вам нужно было обойтись без каких-либо коммитов, пока вы снова не подключились. С помощью DVCS вы можете совершать локальные (и возвращать, ветвь и т.д.), А затем возвращать эти коммиты, когда вы возвращаетесь домой.

Ответ 3

Действительно сильное преимущество как git, так и меркуриального в настройке "домашнего проекта" заключается в том, что новый репозиторий тривиально настраивается. В git вы просто делаете git init в корне вашего кодового дерева, и у вас есть новый репозиторий.

Затем вы можете добавить, зафиксировать, разветкить и т.д. сразу. svn имеет большие затраты на настройку, поскольку вам необходимо создать отдельное местоположение и URL-адрес репозитория, прежде чем вы сможете создать рабочую копию и начать обычные операции VCS.

Хранение документов не проблема в git или меркуриальном, но, конечно же, с git (не уверен в hg). Я бы посоветовал не хранить большие медиафайлы (что-то от 100 М вверх), поскольку он не очень хорошо работает в некоторых операции.

Ответ 4

Я использую git для личных проектов, чтобы "сотрудничать с самим собой". У меня есть хранилища в окне linux в моей домашней сети, которые доступны через туннель из любого места. Затем я буду клонировать его на свой домашний рабочий стол, мой ноутбук, может быть, на работе, и я вижу это или работаю над этим в любом месте. Я могу совершать изменения, получать последние и иметь резервные копии в разных местах. Очень приятная легкость и скорость, с которыми git позволяет вам переключаться между ветвями. Найдена ошибка? Переключитесь на "мастер", исправьте его, зафиксируйте, нажмите, а затем вернитесь к тому, что вы делаете. Легче и быстрее, чем cvs или subversion.

Кроме того, я использую git для небольших каталогов, которые даже не являются проектами. Каталог конфигурации для сервера apache, на котором размещен мой веб-сайт, - git 'd, а также каталог конфигурации tomcat для того же веб-сайта.

Я использую его на работе для всего, даже несмотря на то, что мы работаем над CVS, переходящим в Subversion. Я не использую git -cvs или git -svn, я просто использую git рядом с любым продуктом и сохраняю свои ветки локальными. Очень удобно, чтобы иметь возможность переключиться на другой компилятор последнего разработчика, проверить что-то, а затем отменить.

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

Кроме того, если на работе они все еще используют перфокарты, cvs или subversion, то использование git дома - отличный способ оставаться в курсе событий, а также выяснить, какое влияние оно может иметь.

Я не волнуюсь о технологиях, если они не приносят что-то действительно новое в таблицу. git. Я - фанат. Вероятно, вы уже поняли это.

Ответ 5

Помимо подробностей о многих замечательных чертах hg, git, darcs, bzr и друзей (без сарказма, я большой поклонник), основные моменты здесь:

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

• С любым распределенным VCS тривиально создавать один или несколько "клонов" вашего "репо". Вы можете фиксировать изменения локально в любое время, быстро, а затем нажимать эти изменения на удаленное репо, когда доступно подключение.

git, hg и другие загружаются функциями (и ошибками), которые делают их отличными от svn и cvs. Но это основное.

Ответ 6

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

Главное преимущество заключается в том, что вы несете весь репозиторий на своем ноутбуке! Это может занять некоторое время, чтобы оценить, что это на самом деле означает, когда вы привыкли к массивным центральным хранилищам и всем связанным с этим проблемам. Конечно, во многих ситуациях полезно иметь одно, но снова, вы можете контролировать, кто имеет и какой доступ к нему. Благодаря централизованному vcs, не позволяющему кому-либо напрямую связываться с центральным хранилищем, это означает много дополнительной работы от какого-то несчастного дерна. Коммиты должны быть сделаны более или менее вручную, а с помощью dvcs дерн, ответственный за проверку кода, может передать их точно так же, как и на своем компьютере, как и собственный код.

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

Я бы сказал, что чем больше работа выполняется за пределами вашей сети компании, тем более выгодны dvcs. Если у вас есть быстрый доступ к центральному репозиторию, и всем можно доверять, чтобы зафиксировать их изменения там, то основные силы dvcs не так важны (хотя все еще есть некоторые, но на данный момент они являются ИМО сбалансированными с бедным пользовательским интерфейсом).

Ответ 7

Я не знаю о mercurial, но моя любимая вещь в git, которая невозможна в subversion, - это редактирование истории. Например, вы можете:

• изменить предыдущие коммиты, чтобы внести изменения в список файлов, которые были изменены
• изменить порядок предыдущих коммитов
• удалить полностью из истории
• объединить два или более коммита. Разделение
• разделяется на части
• добавить последующие изменения в предыдущие коммиты

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

Ответ 8

Я хочу подчеркнуть, что Mercurial и GIT запускаются с помощью элемента управления источником без необходимости сервера и позволяют легко перемещать ваш репозиторий на другой сервер при необходимости.

Другие преимущества были рассмотрены в других ответах.

Ответ 9

Раньше у меня был сервер subversion для домашней синхронизации. Несколько лет я запускал git, но теперь перешел на hg. Причина в основном простота. Я должен уметь "мастер" git, но все же я этого не делаю.

Здесь отличный учебник от Joel (один из создателей StackOverflow) на hg.