Для домашних проектов, может Подвижный или Мерзавец (или другой DVCS) обеспечивают больше преимуществ перед Подверсией? [закрытый]
7 ответов
Посмотрите на части об управлении версиями для одного разработчика в моем ответе на вопрос « Разница между 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 'Initial commit'» "для создания первой фиксации).В Subversion (в любой централизованной системе управления версиями) вам необходимо настроить центральный репозиторий (если вы не сделали этого раньше) с помощью команды svnadmin create (ну, вам нужно сделать это только один раз) . Затем вам нужно импортировать файлы в Subversion, используя " ignore ) хранятся в каталоге
.svnв каждом каталоге вашего проекта. (Обратите внимание, что Subversion хранит исходную копию вашей кассы, чтобы иметь быстрые «svn status» и «svn diff»)Присвоение имен ревизиям / номерам версий. Subversion использует глобальные идентификаторы ревизии в виде единственного числа, указывающего ревизию (так что вы можете, например, обратиться к r344, ревизия 344). Subversion также поддерживает несколько символических спецификаторов ревизии: HEAD, BASE, COMITTED, PREV.
В Git каждая версия проекта (каждая фиксация) имеет свое уникальное имя, заданное 40 шестнадцатеричным идентификатором SHA-1; обычно первых 7-8 символов достаточно для идентификации фиксации (вы не можете использовать простую схему нумерации для версий в распределенной системе контроля версий - для этого требуется центральный орган нумерации). Но Git предлагает и другие виды спецификаторов ревизии, например
HEAD ^означает родительский элемент текущего коммита,master ~ 5означает, что предки ревизии 5 вернулись (в прямой строке первого родителя) из top commit на «главной» ветке,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 blame». Я слышал, что он не работает правильно в более сложных ситуациях (перекрестное слияние) и в настоящее время не может работать с переименованием (в этом случае даже есть вероятность тихого повреждения). См. Также (например) это сообщение Дмитрия Потапова в списке рассылки git , в котором объясняется предполагаемый вариант использованияsvn: mergeinfoи его (текущие) ограничения.Тегирование. ] В Git теги неизменяемы , могут иметь связанный с ними комментарий и могут быть подписаны с использованием подписи PGP / GPG (и проверены). Они сделаны с помощью "git tag". Вы можете ссылаться на ревизию, используя имя тега.
В тегах Subversion используется то же соглашение о пространстве имен path_info , что и для ветвей (рекомендуемое соглашение
svnroot / project / tags / tagname), и они не защищены от изменения. Они сделаны с использованием "svn copy". Они могут иметь комментарий, связанный с [фиксацией создания тега].Расширение ключевого слова. Git предлагает очень и очень ограниченный набор ключевых слов по сравнению с Subversion (по умолчанию). Это связано с двумя фактами: изменения в Git происходят для каждого репозитория, а не для каждого файла, и Git избегает модификации файлов, которые не изменились при переключении на другую ветку или при переходе к другой точке истории. Если вы хотите встроить номер версии с помощью Git, вы должны сделать это с помощью своей системы сборки, например следующий пример сценария GIT-VERSION-GEN в исходных кодах ядра Linux и в исходных текстах Git. Существует также
'идентификатор'gitattribute, который позволяет расширение ключевого слова «$ Id $» до идентификатора SHA-1 содержимого файла (не идентификатора фиксации).Оба Git и Subversion расширяют ключевые слова только по запросу.
Двоичные файлы. И Git, и Subversion правильно работают с двоичными файлами. Git выполняет обнаружение двоичных файлов с использованием алгоритма, аналогичного тому, который используется, например, GNU diff, если только это не переопределено для каждого пути с помощью gitattributes. Subversion делает это немного по-другому, определяя тип файла при добавлении файла и устанавливая свойство
svn: mime-type, которое вы затем можете изменить. И Git, и Subversion могут выполнять преобразование символа конца строки по запросу; Git дополнительно имеет параметр конфигурацииcore.safecrlf, который предупреждает и предотвращает необратимое изменение (все CR для всех CRLF обратимы, смешанные CR и CRLF необратимы).Игнорирование файлов. Git хранит шаблоны игнорирования с помощью файла в дереве
.gitignore, который можно поставить под контроль версий и распространить; обычно он содержит шаблоны для продуктов сборки и других сгенерированных файлов, а также в файле.git / info / excludes, который обычно содержит шаблоны игнорирования, специфичные для пользователя или системы, например, игнорировать шаблон для файлов резервных копий вашего редактора. Шаблоны Git применяются рекурсивно, если шаблон не содержит разделитель каталогов, то есть символ косой черты '/', тогда он привязан к каталогу.gitignoreфайл; в верхний каталог для.git / info / excludes. (Существует также конфигурационная переменнаяcore.excludesfile; эта переменная может существовать в файле конфигурации для каждого пользователя~ / .gitconfigи указывать на файл игнорирования для каждого пользователя).Subversion использует параметр конфигурации среды выполнения
global-ignores(который обычно применяется к конкретному компьютеру или конкретным пользователем компьютера) и свойство «svn: ignore» в каталогах с версиями SVN. Однако, в отличие от параметраglobal-ignore(и в.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> Хостинг проекта (Фронт освобождения данных) статья
См. также сайт http://whygitisbetterthanx.com/ .
С другой стороны, например, Google Code предлагает использовать инструмент svnsync (часть стандартного дистрибутива Subversion), как описано в Продукты Google> Хостинг проектов (Фронт освобождения данных) статьяСм. также сайт http://whygitisbetterthanx.com/ .
С другой стороны, например, Google Code предлагает использовать инструмент svnsync (часть стандартного дистрибутива Subversion), как описано в Продукты Google> Хостинг проекта (Фронт освобождения данных) статьяСм. также сайт http://whygitisbetterthanx.com/ .
Одно очевидное преимущество: вы можете развиваться, когда вы находитесь вдали от сервера. Например, у вас может быть ноутбук с собственным локальным репозиторием git, и вы можете отправить его на свой сервер (или github). Теперь предположим, что вы ушли куда-то без подключения к Интернету ... в Subversion вам придется обходиться без каких-либо коммитов, пока вы не подключитесь снова. С помощью DVCS вы можете фиксировать локально (и возвращаться, переходить и т. Д.), А затем возвращать эти фиксации обратно, когда вернетесь домой.
Действительно сильным преимуществом как git, так и mercurial в настройке «домашнего проекта» является то, что новый репозиторий настраивается несложно. В git вы просто выполняете git init в корне своего дерева кода, и у вас есть новый репозиторий.
Затем вы можете сразу добавить, зафиксировать, ветвиться и т. Д. svn требует больших затрат на установку, так как вам нужно отдельное местоположение репозитория и URL-адрес, прежде чем вы сможете создать рабочую копию и начать свои обычные операции VCS.
Хранение документов не проблема в git или mercurial, но, конечно, с git (не уверен about hg) Я бы не советовал хранить большие медиафайлы (размером от 100 Мбайт и выше), поскольку они не очень хорошо работают в некоторых операциях.
Совместное использование проектов намного проще с dvcs, потому что вам не нужно предоставлять другим доступ к вашему компьютеру с центральным репозиторием. Вы можете попросить его создать копию и запретить ему делать какие-либо коммиты где угодно, если хотите. Если вам нужны его изменения, вы можете перетащить их с его компьютера куда угодно, а не позволять ему продвигать их. Таким образом, вы можете, если хотите, сначала проверить изменения. Вы полностью контролируете (если хотите).
Главное преимущество по-прежнему заключается в том, что вы несете весь репозиторий на своем ноутбуке! Может потребоваться время, чтобы понять, что это на самом деле означает, когда вы привыкли к огромным центральным репозиториям и всем сопутствующим хлопотам. Конечно, во многих ситуациях его полезно иметь, но, опять же, вы можете контролировать, кто имеет и какой к нему доступ. С централизованным vcs ' s запрещение кому-либо выполнять фиксацию непосредственно в центральном репозитории означает много дополнительной работы со стороны какого-то несчастного болвана. Коммиты должны быть выполнены более или менее вручную, в то время как с dvcs дерьмо, ответственное за проверку коммитированного кода, может коммитить их точно так же со своего компьютера, как и свой собственный код.
Есть способы облегчить вышеупомянутое в vcs, но они по-прежнему требуют дополнительного обслуживания (создавать компоненты / представления / все, что когда-либо контролируется, и разрешать коммиты только для этого). В git / mercurial на самом деле нет никаких этих накладных расходов.
Я бы сказал, что чем больше работы выполняется за пределами сети вашей компании, тем более выгодными являются DVD-диски. Если у всех вас есть быстрый доступ к центральному репозиторию и всем можно доверить фиксацию своих изменений там, то основные сильные стороны dvcs '
Помимо подробностей о многих замечательных функциях hg, git, darcs, bzr и друзей (без сарказма; я большой поклонник), здесь можно найти самое необходимое:
svn вы должны выбрать между хранением репо вне сайта и хранением его на месте. На месте означает, что если ваш диск выйдет из строя, ваш проект станет тостом. Offsite означает, что вы не можете выполнить фиксацию из самолета или в других ситуациях с отключением, а когда сетевое соединение плохое, фиксация может быть медленной.
С любой распределенной VCS это тривиально для создания одного или нескольких «клонов» вашего «репо». Вы можете зафиксировать изменения локально в любое время, быстро, а затем отправить эти изменения в удаленное хранилище, когда соединение доступно.
git, hg, и другие загружены функциями (и ошибками), которые отличают их от svn и cvs. Но это самое главное.
Я использую git в личных проектах для своего рода «сотрудничества с самим собой». У меня есть репозитории на Linux-сервере в моей домашней сети, которые доступны через туннель из любого места. Затем я клонирую его на свой домашний рабочий стол, свой ноутбук, может быть, компьютер на работе, и я смогу увидеть его или поработать на нем где угодно. Я могу фиксировать изменения, получать последние новости и делать резервные копии в разных местах. Очень приятно, насколько легко и быстро git позволяет переключать ветки. Нашли ошибку? Переключитесь на «мастер», исправьте, зафиксируйте, нажмите, а затем вернитесь к тому, что делаете. Проще и быстрее, чем cvs или subversion.
Кроме того, я часто использую git для небольших каталогов, которые даже не являются проектами. Каталог конфигурации для сервера apache, на котором размещен мой веб-сайт, - это git'd, а также каталог конфигурации tomcat для того же веб-сайта.
Я использую его на работе для всего, хотя на работе мы переходим с CVS на Subversion. Я не использую git-cvs или git-svn, я просто использую git вместе с любым продуктом и сохраняю свои ветки локальными. Очень удобно, чтобы иметь возможность переключиться на последний коммит другого разработчика, проверить что-то, а затем переключиться обратно.
Затем, конечно, есть деление пополам, которое может быть огромным подспорьем для рабочих или домашних проектов.
Также, если на работе они все еще используют перфокарты, резюме или подрывную деятельность, тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние это может оказать.
Я не в восторге от технологий если только они не принесут на стол что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
re о переходе CVS на Subversion. Я не использую git-cvs или git-svn, я просто использую git вместе с любым продуктом и сохраняю свои ветки локальными. Очень удобно, чтобы иметь возможность переключиться на последний коммит другого разработчика, проверить что-то, а затем переключиться обратно.Затем, конечно, есть деление пополам, которое может быть огромным подспорьем для рабочих или домашних проектов.
Также, если на работе они все еще используют перфокарты, резюме или подрывную деятельность, тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние это может оказать.
Я не в восторге от технологий если только они не принесут на стол что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
re о переходе CVS на Subversion. Я не использую git-cvs или git-svn, я просто использую git вместе с любым продуктом и оставляю свои ветки локальными. Очень удобно, чтобы иметь возможность переключиться на последний коммит другого разработчика, проверить что-то, а затем переключиться обратно.Затем, конечно, есть деление пополам, которое может быть огромным подспорьем для рабочих или домашних проектов.
Также, если на работе они все еще используют перфокарты, резюме или подрывную деятельность, тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние это может оказать.
Я не в восторге от технологий если только они не принесут на стол что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
Очень удобно, чтобы иметь возможность переключиться на последний коммит другого разработчика, проверить что-то, а затем переключиться обратно.Затем, конечно, есть деление пополам, которое может быть огромным подспорьем для рабочих или домашних проектов.
Также, если на работе они все еще используют перфокарты, резюме или подрывную деятельность, тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние это может оказать.
Я не в восторге от технологий если только они не принесут на стол что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
Очень удобно, чтобы иметь возможность переключиться на последний коммит другого разработчика, проверить что-то, а затем переключиться обратно.Затем, конечно, есть деление пополам, которое может быть огромным подспорьем для рабочих или домашних проектов.
Также, если на работе они все еще используют перфокарты, резюме или подрывную деятельность, тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние это может оказать.
Я не в восторге от технологий если только они не принесут на стол что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние они могут оказать.Я не в восторге от технологий, если они не привносят что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
тогда использование git дома - отличный способ оставаться в курсе событий и самому узнать, какое влияние они могут оказать.Я не в восторге от технологий, если они не привносят что-то действительно новое. Git делает. Я - фанат. Вы, наверное, уже догадались.
Я не знаю о ртути, но мой любимый то, что нужно сделать в git, что невозможно в Subversion, - это редактирование истории. Например, вы можете:
- отредактировать предыдущие коммиты, чтобы внести изменения в список файлов, которые были изменены;
- изменить порядок предыдущих коммитов
- полностью удалить коммиты из истории
- объединить два или более коммитов вместе
- разделить коммиты на части
- добавить последующие изменения к предыдущим коммитам
Короче говоря, если вы думаете, что должны уметь это делать, то, вероятно, сможете. Это очень мощно,