Почему Git лучше Subversion?

08-06-2019
|

Вопрос

Я использовал Подрывная деятельность в течение нескольких лет и после использования Безопасный источник, Я просто обожаю Subversion.В сочетании с TortoiseSVN, Я действительно не могу себе представить, как это могло быть лучше.

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

Как Git улучшается по сравнению с Subversion?

Решение

Git ничем не лучше Subversion.Но и не хуже.Это другое дело.

Ключевое отличие заключается в том, что она децентрализована.Представьте, что вы разработчик в разъездах, вы разрабатываете на своем ноутбуке и хотите иметь систему управления версиями, чтобы вернуться на 3 часа назад.

С Subversion у вас возникла проблема:Репозиторий SVN может находиться в недоступном для вас месте (в вашей компании, и в данный момент у вас нет Интернета), вы не можете зафиксировать.Если вы хотите сделать копию своего кода, вам нужно буквально скопировать / вставить его.

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

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

Git кажется "новой, блестящей, классной" штукой.Это ни в коем случае не плохо (в конце концов, есть причина, по которой Линус написал это для разработки ядра Linux), но я чувствую, что многие люди переходят на "Распределенное управление версиями" только потому, что это ново и написано Линусом Торвальдсом, на самом деле не зная, почему / если это лучше.

У Subversion есть проблемы, но так же, как и у Git, Mercurial, CVS, TFS или чего-то еще.

Редактировать: Итак, этому ответу исполнился год, и он по-прежнему вызывает много положительных отзывов, поэтому я подумал, что добавлю еще несколько пояснений.За последний год, прошедший с момента написания этой статьи, Git приобрел большой импульс и поддержку, особенно после того, как такие сайты, как GitHub, действительно взлетели.В настоящее время я использую как Git, так и Subversion, и я хотел бы поделиться некоторыми личными соображениями.

Прежде всего, Git поначалу может действительно сбивать с толку при децентрализованной работе.Что такое пульт дистанционного управления?и как правильно настроить начальный репозиторий?это два вопроса, которые возникают в начале, особенно по сравнению с простым SVN "svnadmin create", Git "git init" Git может принимать параметры --bare и --shared, что, по-видимому, является "правильным" способом настройки централизованного репозитория.Для этого есть причины, но это добавляет сложности.Документация команды "checkout" очень сбивает с толку людей, перестраивающихся - "правильный" способ, похоже, "git clone", в то время как "git checkout", похоже, переключает ветви.

Git ДЕЙСТВИТЕЛЬНО сияет, когда вы децентрализованы.У меня есть сервер дома и ноутбук в дороге, и SVN здесь просто плохо работает.С SVN у меня не может быть локального управления версиями, если я не подключен к репозиторию (Да, я знаю о SVK или о способах копирования репозитория).В любом случае, в Git это режим по умолчанию.Однако это дополнительная команда (git commit фиксирует локально, в то время как git push origin master отправляет главную ветвь на удаленный сервер с именем "origin").

Как было сказано выше:Git добавляет сложности.Два режима создания репозиториев: checkout иклонирование, фиксация противтолкать...Вы должны знать, какие команды работают локально, а какие - с "сервером" (я предполагаю, что большинству людей все еще нравится центральный "мастер-репозиторий").

Кроме того, инструментария по-прежнему недостаточно, по крайней мере, в Windows.Да, есть надстройка Visual Studio, но я все еще использую git bash с msysgit.

Преимущество SVN в том, что его НАМНОГО проще освоить:Вот ваш репозиторий, все изменения, внесенные в него, если вы знаете, как создавать, фиксировать и извлекать, и вы готовы к работе и можете выполнять такие вещи, как ветвление, обновление и т.д.позже.

Преимущество Git в том, что он ГОРАЗДО лучше подходит, если некоторые разработчики не всегда подключены к главному репозиторию.Кроме того, это намного быстрее, чем SVN.И из того, что я слышал, поддержка ветвления и слияния намного лучше (чего и следовало ожидать, поскольку это основные причины, по которым она была написана).

Это также объясняет, почему он пользуется таким ажиотажем в Интернете, поскольку Git идеально подходит для проектов с открытым исходным кодом:Просто разветвляйте его, зафиксируйте свои изменения в своем собственном форке, а затем попросите разработчика исходного проекта извлечь ваши изменения.С Git это просто работает.Действительно, попробуйте это на Github, это волшебно.

То, что я также вижу, - это мосты Git-SVN:Центральный репозиторий - это репозиторий Subversion, но разработчики локально работают с Git, а затем мост отправляет их изменения в SVN.

Но даже с этим пространным дополнением я по-прежнему придерживаюсь своего основного послания:Git не лучше и не хуже, он просто другой.Если у вас есть потребность в "Автономном управлении версиями" и желание потратить дополнительное время на его изучение, это просто фантастика.Но если у вас строго централизованный контроль версий и / или вы изо всех сил пытаетесь внедрить контроль версий в первую очередь потому, что ваши коллеги не заинтересованы, тогда простота и отличный инструментарий (по крайней мере, в Windows) SVN великолепны.

Другие советы

С Git вы можете делать практически все, что угодно, в автономном режиме, потому что у каждого есть свой собственный репозиторий.

Создавать ветви и объединять их между собой действительно просто.

Даже если у вас нет прав на фиксацию для проекта, вы все равно можете иметь свой собственный репозиторий в Интернете и публиковать "push-запросы" для ваших исправлений.Все, кому понравились ваши патчи, могут использовать их в своем проекте, включая официальных сопровождающих.

Тривиально разветвлять проект, изменять его и при этом продолжать объединять исправления ошибок из ГОЛОВНОЙ ветки.

Git работает для разработчиков ядра Linux.Это означает, что это действительно быстро (так и должно быть) и масштабируется для тысяч участников.Git также использует меньше места (до 30 раз меньше места для репозитория Mozilla).

Git очень гибкий, очень своевременный (существует более одного способа сделать это).Вы можете использовать любой рабочий процесс, который захотите, и Git поддержит его.

Наконец, есть ГитХаб, отличный сайт для размещения ваших репозиториев Git.

Недостатки Git:

этому гораздо сложнее научиться, потому что в Git больше концепций и команд.
редакции не имеют номеров версий, как в subversion
многие команды Git являются загадочными, а сообщения об ошибках очень недружелюбны к пользователю
ему не хватает хорошего графического интерфейса (такого как отличный TortoiseSVN)

Другие ответы проделали хорошую работу по объяснению основных функций Git (которые просто великолепны).Но их также так много маленький способы, которыми Git ведет себя лучше и помогает сохранить мою жизнь более разумной.Вот некоторые из этих мелочей:

У Git есть "чистая" команда.SVN отчаянно нуждается в этой команде, учитывая, как часто она будет сбрасывать дополнительные файлы на ваш диск.
В Git есть команда "разделить пополам".Это мило.
SVN создает каталоги .svn в каждой отдельной папке (Git создает только один каталог .git).Каждый сценарий, который вы пишете, и каждый grep, который вы выполняете, должны быть написаны так, чтобы игнорировать эти каталоги .svn.Вам также понадобится целая команда ("svn export") только для того, чтобы получить нормальную копию ваших файлов.
В SVN каждый файл и папка могут быть получены из другой редакции или ветви.Поначалу кажется приятным обладать такой свободой.Но на самом деле это означает, что существует миллион различных способов полностью испортить вашу локальную кассу.(например, если "svn switch" завершается с ошибкой на полпути или если вы неправильно ввели команду).И самое худшее, что:если вы когда-нибудь попадете в ситуацию, когда некоторые из ваших файлов поступают из одного места, а некоторые из них - из другого, "статус svn" сообщит вам, что все нормально.Вам нужно будет сделать "svn info" для каждого файла / каталога, чтобы узнать, насколько странные вещи происходят.Если "git status" говорит вам, что все нормально, то вы можете быть уверены, что все действительно нормально.
Вы должны сообщать SVN всякий раз, когда вы что-то перемещаете или удаляете.Мерзавец просто разберется в этом.
Игнорировать семантику в Git проще.Если вы игнорируете шаблон (например, *.pyc), он будет проигнорирован для ВСЕ подкаталоги.(Но если вы действительно хотите игнорировать что-то только для одного каталога, вы можете).С SVN кажется, что нет простого способа игнорировать шаблон во всех подкаталогах.
Еще один элемент, связанный с игнорированием файлов.Git позволяет иметь "частные" настройки игнорирования (используя файл .git/info/exclude), которые не повлияют ни на кого другого.

"Почему Git лучше, чем X" описывает различные плюсы и минусы Git по сравнению с другими SCM.

Кратко:

Треки Git контент, а не файлы
Ветви легкие и слияние - это легко, и я имею в виду действительно просто.
Он распределен, по сути, каждый репозиторий является филиалом.На мой взгляд, разрабатывать одновременно и совместно намного проще, чем с Subversion.Это также делает Не в сети возможно развитие.
IT не навязывает никакого рабочего процесса, как видно на приведенный выше веб-сайт, на который дана ссылка, С помощью Git возможно множество рабочих процессов.Рабочий процесс в стиле Subversion легко имитируется.
Репозитории Git - это гораздо меньший по размеру файл чем репозитории Subversion.Существует только один каталог ".git", в отличие от десятков репозиториев ".svn" (обратите внимание на Subversion 1.7 и выше теперь используется один каталог как Мерзавец.)
Тот Самый постановка область потрясающая, она позволяет вам видеть изменения, которые вы собираетесь внести, вносить частичные изменения и выполнять различные другие действия.
Припрятывание это бесценно, когда вы занимаетесь "хаотичной" разработкой или просто хотите исправить ошибку, пока вы все еще работаете над чем-то другим (в другой ветке).
Ты можешь переписать историю, который отлично подходит для подготовки наборов исправлений и исправления ваших ошибок (до того, как вы публикуете коммиты)
... и еще лот Еще.

Есть некоторые недостатки:

Для этого пока существует не так много хороших графических интерфейсов.Это новинка, а Subversion существует намного дольше, так что это естественно, поскольку в разработке находится несколько интерфейсов.Некоторые хорошие из них включают в себя Черепаший укус и GitHub для Mac.
Частичные проверки / клоны репозиториев на данный момент невозможны (я читал, что это находится в разработке).Однако существует поддержка подмодулей. Git 1.7 + поддерживает редкие проверки.
Возможно, этому будет сложнее научиться, хотя я и не считал, что это так (около года назад).Git недавно улучшил свой интерфейс и стал довольно удобным для пользователя.

В самом упрощенном варианте Subversion и Git - это практически одно и то же.Нет большой разницы между:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Где Git действительно блистает, так это ветвление и работа с другими людьми.

Технический разговор в Google:Линус Торвальдс о git

http://www.youtube.com/watch?v=4XpnKHJAok8

Страница сравнения Git Wiki

http://git.or.cz/gitwiki/GitSvnComparsion

Что ж, это распространено.Тесты показывают, что это значительно быстрее (учитывая его распределенный характер, все операции, такие как diffs и logs, являются локальными, поэтому, конечно, в данном случае это невероятно быстрее), а рабочие папки меньше (что все еще поражает меня воображение).

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

При распределенном управлении версиями у вас есть не моментальный снимок, а скорее вся кодовая база.Хотите сделать различие с версией 3-месячной давности?Нет проблем, версия 3-месячной давности все еще установлена на вашем компьютере.Это не только означает, что все происходит намного быстрее, но и если вы отключены от своего центрального сервера, вы все равно можете выполнять многие операции, к которым привыкли.Другими словами, у вас есть не просто снимок данной версии, но и всей кодовой базы.

Можно подумать, что Git займет кучу места на вашем жестком диске, но, судя по паре тестов, которые я видел, на самом деле это занимает меньше.Не спрашивай меня, как.Я имею в виду, что он был создан Лайнусом, я думаю, он кое-что смыслит в файловых системах.

Основные моменты, которые мне нравятся в DVCS, таковы :

Вы можете совершать сломанные поступки.Это не имеет значения, потому что другие люди не увидят их, пока вы не опубликуете.Время публикации отличается от времени фиксации.
Из-за этого вы можете совершать покупки чаще.
Вы можете объединить полную функциональность.Эта функциональность будет иметь свою собственную ветвь.Все коммиты этой ветви будут связаны с этой функциональностью.Вы можете сделать это с помощью CVCS, однако с DVCS это используется по умолчанию.
Вы можете выполнить поиск в своей истории (узнать, когда менялась функция).
Вы можете отменить удаление, если кто-то испортил основной репозиторий, вам не нужно исправлять ошибки.Просто очистите слияние.
Когда вам нужен элемент управления версиями в любом каталоге, выполните следующие действия :git инициализирует .и вы можете зафиксировать, отменить изменения и т.д...
Это быстро (даже в Windows).

Основной причиной относительно большого проекта является улучшенная коммуникация, созданная пунктом 3.Другие - приятные бонусы.

Самое смешное, что:Я размещаю проекты в репозиториях Subversion, но получаю к ним доступ через команду Git Clone.

Пожалуйста, прочтите Разработка с помощью Git в проекте Google Code

Хотя Google Code изначально говорит на языке Subversion, вы можете легко использовать Git во время разработки.Поиск "git svn" предполагает, что эта практика широко распространена, и мы также рекомендуем вам поэкспериментировать с ней.

Использование Git в репозитории Svn дает мне преимущества:

Я могу работать распределенный на нескольких машинах, фиксируя и извлекая из и к ним
У меня есть центральный backup/public репозиторий svn для ознакомления другим пользователям
И они могут свободно использовать Git для своих собственных

Все ответы здесь, как и ожидалось, ориентированы на программиста, однако что произойдет, если ваша компания использует контроль версий вне исходного кода?Существует множество документов, которые не являются исходным кодом, которые выигрывают от контроля версий и должны находиться рядом с кодом, а не в другой CMS.Большинство программистов не работают изолированно - мы работаем на компании как часть команды.

Имея это в виду, сравните простоту использования Subversion и git как в клиентских инструментах, так и в обучении.Я не вижу сценария, при котором Любой распределенную систему контроля версий будет проще использовать или объяснить непрограммисту.Я бы хотел, чтобы мне доказали обратное, потому что тогда я смог бы оценить git и на самом деле иметь надежду на то, что он будет принят людьми, которым нужен контроль версий, которые не являются программистами.

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

Отказ от ответственности:Я заинтересовался Subversion очень рано (примерно в версии 0,29), поэтому, очевидно, я предвзят, но компании, в которых я работал с тех пор, извлекают выгоду из моего энтузиазма, потому что я поощрял и поддерживал его использование.Я подозреваю, что именно так это происходит с большинством компаний-разработчиков программного обеспечения.Учитывая, что так много программистов переходят на сторону git, интересно, сколько компаний упустят преимущества использования контроля версий вне исходного кода?Даже если у вас есть отдельные системы для разных команд, вы упускаете некоторые преимущества, такие как (унифицированная) интеграция отслеживания проблем, одновременно увеличивая требования к техническому обслуживанию, оборудованию и обучению.

Subversion по-прежнему является гораздо более используемой системой контроля версий, что означает, что она обладает лучшей инструментальной поддержкой.Вы найдете готовые плагины SVN практически для любого IDE, и доступны хорошие расширения для проводника (например, TurtoiseSVN).В остальном я вынужден согласиться с Майкл:Git не лучше и не хуже Subversion, он другой.

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

Конечно, в SubVersion есть Tortoise, который [обычно] очень хорош.

Блог Дэвида Ричардса ВАНдиско о Subversion / GIT

Появление GIT принесло с собой породу фундаменталистов DVCS - "гиттеронов’, – которые считают все, что угодно, кроме GIT, дерьмом.Гиттероны, похоже, думают, что разработка программного обеспечения происходит на их собственном острове, и часто забывают, что в большинстве организаций работают не только старшие инженеры-программисты.Это нормально, но остальная часть рынка думает иначе, и я рад это доказать:На последний взгляд, GIT занимал менее трех процентов рынка, в то время как Subversion насчитывает около пяти миллионов пользователей и около половины всего рынка.

Проблема, которую мы увидели, заключалась в том, что гиттероны стреляли (дешевыми) выстрелами в Subversion.Твиты типа “Subversion такая [медленная / дерьмовая / ограничительная / нехорошо пахнет / странно смотрит на меня], а теперь у меня есть GIT и [в моей жизни все работает / моя жена забеременела / У меня появилась девушка после 30 лет попыток / Я выиграл шесть раз подряд за столом для игры в блэкджек].Вы понимаете картину.

Git также делает ветвление и слияние действительно простыми.Subversion 1.5 только что добавила отслеживание слияний, но Git все равно лучше.С помощью Git ветвление происходит очень быстро и дешево.Это делает создание ветки для каждой новой функции более осуществимым.О, и репозитории Git очень эффективны с точки зрения объема памяти по сравнению с Subversion.

Все дело в простоте использования / шагах, необходимых для того, чтобы что-то сделать.

Если я разрабатываю один проект на своем ПК / ноутбуке, git лучше, потому что его намного проще настроить и использовать.Вам не нужен сервер, и вам не нужно постоянно вводить URL репозитория при выполнении слияний.

Если бы это были всего 2 человека, я бы сказал, что git также проще, потому что вы можете просто нажимать и тянуть друг у друга.

Однако, как только вы выйдете за рамки этого, я бы выбрал subversion, потому что на этом этапе вам нужно настроить "выделенный" сервер или местоположение.

Вы можете сделать это так же хорошо с помощью git, как и с SVN, но преимущества git перевешиваются необходимостью выполнять дополнительные шаги для синхронизации с центральным сервером.В SVN вы просто фиксируете.В git вы должны выполнить git commit, затем git push.Дополнительный шаг начинает раздражать просто потому, что в конечном итоге вы делаете это так часто.

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

Простой Мерзавец имеет хорошую страницу, сравнивающую фактическое использование Git и SVN это даст вам представление о том, что Git может делать (или что сделать проще) по сравнению с SVN.(Технически, это основано на Easy Git, который представляет собой облегченную оболочку поверх Git.)

Git и DVCS в целом отлично подходят для разработчиков, выполняющих много кодирования независимо друг от друга, потому что у каждого есть своя ветка.Однако, если вам нужны изменения от кого-то другого, она должна зафиксировать их в своем локальном репозитории, а затем она должна передать вам этот набор изменений, или вы должны забрать его у нее.

Мои собственные рассуждения также заставляют меня думать, что DVCS усложняет контроль качества и управление выпусками, если вы делаете такие вещи, как централизованные выпуски.Кто-то должен нести ответственность за выполнение этого push / pull из репозитория всех остальных, разрешение любых конфликтов, которые были бы разрешены во время начальной фиксации ранее, затем выполнение сборки, а затем повторная синхронизация репозиториев всеми другими разработчиками.

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

Мне нравится Git, потому что он действительно помогает общаться разработчикам в команде от среднего до большого размера.Как распределенная система контроля версий, благодаря своей системе push / pull она помогает разработчикам создавать экосистему исходного кода, которая помогает управлять большим пулом разработчиков, работающих над одним проектом.

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

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

В нескольких ответах упоминались эти вопросы, но я хочу четко обозначить 2 момента:

1) Возможность выполнять выборочные коммиты (например, git add --patch).Если ваш рабочий каталог содержит несколько изменений, которые не являются частью одного и того же логического изменения, Git очень упрощает выполнение фиксации, включающей только часть изменений.С Subversion это сложно.

2) Возможность фиксировать изменения, не предавая их огласке.В Subversion любая фиксация немедленно становится общедоступной и, следовательно, безотзывной.Это сильно ограничивает возможности разработчика "совершать коммиты рано, совершать коммиты часто".

Git - это больше, чем просто VCS;это также инструмент для разработки исправлений.Subversion - это всего лишь венчурный капитал.

Я думаю, что Subversion - это прекрасно..пока вы не начнете сливаться..или делать что-нибудь сложное..или делать что-либо, что Subversion считает сложным (например, выполнять запросы, чтобы выяснить, какие ветви перепутались с конкретным файлом, где произошло изменение на самом деле исходит из, обнаружение копирования и вставок и т.д.)...

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

Просто он невероятно мощный, быстрый и, ну, после привыкания к концепциям, очень полезный (да, в этом смысле:удобный для пользователя).

Для получения более подробной информации об истории слияния смотрите Это :Используете git-svn (или аналогичный) * просто *, чтобы помочь со слиянием svn?

Благодаря тому, что ему не нужно постоянно взаимодействовать с центральным сервером, практически каждая команда выполняется менее чем за секунду (очевидно, что git push / pull / fetch работают медленнее просто потому, что им приходится инициализировать SSH-соединения).Ветвление намного проще (одна простая команда для ветвления, одна простая команда для объединения).

Мне очень нравится иметь возможность управлять локальными ветвями моего исходного кода в Git, не замутняя воду в центральном репозитории.Во многих случаях я извлекаю код с сервера Subversion и запускаю локальный репозиторий Git, просто чтобы иметь возможность это сделать.Также здорово, что инициализация репозитория Git не загрязняет файловую систему кучей раздражающих папок .svn повсюду.

Что касается поддержки инструментов Windows, TortoiseGit очень хорошо справляется с основами, но я по-прежнему предпочитаю командную строку, если только не хочу просматривать журнал.Мне действительно нравится, как Tortoise{Git| SVN} помогает при чтении журналов фиксации.

Это неправильный вопрос, который следует задавать.Слишком просто сосредоточиться на недостатках git и сформулировать аргумент о том, почему subversion якобы лучше, по крайней мере, для некоторых вариантов использования.Тот факт, что git изначально разрабатывался как набор конструкторов для низкоуровневого контроля версий и имеет интерфейс, ориентированный на разработчиков в стиле барокко linux, облегчает holy wars завоевание популярности и восприятие легитимности.Сторонники Git бьют в барабан миллионами преимуществ рабочего процесса, которые ребята из svn объявляют ненужными.Довольно скоро вся дискуссия оформляется как централизованная против распределенной, что отвечает интересам сообщества корпоративных инструментов svn.Эти компании, которые обычно публикуют наиболее убедительные статьи о превосходстве subversion на предприятии, зависят от воспринимаемой незащищенности git и корпоративной готовности svn к долгосрочному успеху своих продуктов.

Но вот в чем проблема: Subversion - это архитектурный тупик.

В то время как вы можете взять git и довольно легко создать централизованную замену subversion, несмотря на то, что svn работает более чем в два раза дольше, svn никогда не удавалось заставить даже базовое отслеживание слияний работать так же хорошо, как в git.Одной из основных причин этого является дизайнерское решение сделать ветви такими же, как каталоги.Я не знаю, почему они изначально пошли этим путем, но это, безусловно, упрощает частичную проверку.К сожалению, это также делает невозможным правильное отслеживание истории.Теперь, очевидно, вы должны использовать соглашения о макете репозитория subversion для отделения ветвей от обычных каталогов, а svn использует некоторую эвристику, чтобы заставить вещи работать в повседневных случаях использования.Но все это просто обклеивание бумагой очень плохого и ограниченного низкоуровневого дизайнерского решения.Возможность выполнять различие по репозиторию (а не по каталогу) является базовой и критически важной функциональностью для системы контроля версий и значительно упрощает внутреннюю часть, позволяя создавать более умные и полезные функции поверх нее.Вы можете видеть, сколько усилий было затрачено на расширение subversion, и все же насколько далеко она отстает от текущего набора современных VCSE с точки зрения фундаментальных операций, таких как разрешение слиянием.

Теперь вот мой искренний совет агностика всем, кто все еще верит, что Subversion достаточно хороша в обозримом будущем:

Subversion никогда не догонит новые поколения VCSE, которые извлекли уроки из ошибок RCS и CVS;это техническая невозможность, если только они не переоснастят модель репозитория с нуля, но тогда это не было бы на самом деле svn, не так ли?Независимо от того, насколько вы считаете, что не владеете возможностями современной венчурной системы, ваше невежество не защитит вас от подводных камней Subversion, многие из которых представляют собой ситуации, которые невозможны или легко разрешимы в других системах.

Крайне редко техническая неполноценность решения настолько очевидна, как в случае с svn, конечно, я бы никогда не высказал такого мнения о win-vs-linux или emacs-vs-vi, но в данном случае оно настолько четкое, а контроль версий - настолько фундаментальный инструмент в арсенале разработчика, что я чувствую, что это должно быть заявлено однозначно.Независимо от требования использовать svn по организационным причинам, я умоляю всех пользователей svn не позволять своему логическому мышлению создавать ложное представление о том, что более современные VCSE полезны только для крупных проектов с открытым исходным кодом.Независимо от характера вашей работы по разработке, если вы программист, вы станете более эффективным программистом, если научитесь использовать более совершенные VCS, будь то Git, Mercurial, Darcs или многие другие.

Subversion очень проста в использовании.За последние годы я ни разу не сталкивался с проблемой или с тем, что что-то работает не так, как ожидалось.Также существует множество отличных инструментов с графическим интерфейсом и большая поддержка интеграции SVN.

С Git вы получаете более гибкий VCS.Вы можете использовать его так же, как SVN, с удаленным репозиторием, где вы фиксируете все изменения.Но вы также можете использовать его в основном в автономном режиме и только время от времени отправлять изменения в удаленный репозиторий.Но Git более сложный и имеет более крутую кривую обучения.Я обнаружил, что в первый раз обращаюсь к неправильным веткам, создаю ветки косвенно или получаю сообщения об ошибках с небольшим количеством информации об ошибке и о том, где я должен искать в Google, чтобы получить более точную информацию.Некоторые простые вещи, такие как замена маркеров ($ Id $), не работают, но в GIT есть очень гибкий механизм фильтрации и подключения для объединения собственных скриптов, и поэтому вы получаете все, что вам нужно, и даже больше, но для этого требуется больше времени и чтение документации ;)

Если вы работаете в основном в автономном режиме со своим локальным репозиторием, у вас нет резервной копии, если что-то потеряно на вашем локальном компьютере.С SVN вы в основном работаете с удаленным репозиторием, который одновременно является вашим резервным копированием на другом сервере...Git может работать таким же образом, но это не было главной целью Linus - иметь что-то вроде SVN2.Он был разработан для разработчиков ядра Linux и нужд распределенной системы контроля версий.

Является ли Git лучше SVN?Разработчикам, которым нужна только некоторая история версий и механизм резервного копирования, с SVN живется хорошо и легко.Разработчики, часто работающие с ветками, тестирующие несколько версий одновременно или работающие в основном в автономном режиме, могут извлечь выгоду из возможностей Git.Есть несколько очень полезных функций, таких как сохранение, не найденное с помощью SVN, которые могут облегчить жизнь.Но, с другой стороны, не всем людям понадобятся все функции.Поэтому я не могу видеть мертвых SVN.

Git нуждается в более качественной документации, и отчеты об ошибках должны быть более полезными.Кроме того, существующие полезные графические интерфейсы используются крайне редко.На этот раз я нашел только 1 графический интерфейс для Linux с поддержкой большинства функций Git (git-cola).Интеграция с Eclipse работает, но она официально не выпущена, и официального сайта обновлений нет (только какой-то внешний сайт обновлений с периодическими сборками из магистрали http://www.jgit.org/updates) Итак, наиболее предпочтительным способом использования Git в наши дни является командная строка.

Эрик Синк из источника: написал серию статей о различиях между распределенными и нераспределенными системами контроля версий.Он сравнивает плюсы и минусы большинства популярных систем контроля версий.Очень интересное чтение.
Статьи можно найти в его блоге, www.ericsink.com:

Для людей, ищущих хороший графический интерфейс Git, SmartGit Syntevo это могло бы быть хорошим решением.Его проприетарный, но бесплатный для некоммерческого использования, работает на Windows / Mac / Linux и, я думаю, даже поддерживает SVN, используя какой-то мост git-svn.

http://subversion .wandisco.com/component/content/article/1/40.html

Я думаю, можно с уверенностью сказать, что среди разработчиков SVN Vs.Спор о Git бушует уже некоторое время, и у каждого есть свое мнение о том, что лучше.Этот вопрос даже поднимался в одном из вопросов во время нашего вебинара по Subversion в 2010 году и далее.

Хайрам Райт, наш директор по открытым исходным кодам и президент корпорации Subversion, рассказывает о различиях между Subversion и Git, а также другими системами распределенного контроля версий (DVCS).

Он также рассказывает о предстоящих изменениях в Subversion, таких как Working Copy Next Generation (WC-NG), которые, по его мнению, заставят ряд пользователей Git перейти обратно на Subversion.

Посмотрите его видео и дайте нам знать, что вы думаете, либо прокомментировав в этом блоге, либо разместив сообщение на наших форумах.Регистрация проста и займет всего несколько минут!

Сейчас Git в Windows поддерживается довольно хорошо.

Ознакомьтесь с GitExtensions = http://code.google.com/p/gitextensions/

и руководство для улучшения работы с Windows Git.

В последнее время я живу в Git land, и мне нравится использовать его для личных проектов, но я бы пока не смог переключить на него рабочие проекты из Subversion, учитывая изменение мышления о требованиях от персонала, без каких-либо насущных преимуществ.Более того, самый крупный проект, который мы запускаем собственными силами, чрезвычайно зависит от svn: внешние элементы который, судя по тому, что я видел до сих пор, не работает так хорошо и плавно в Git.

Во-первых, параллельное управление версиями кажется простой проблемой для решения.Это совсем не так.В любом случае...

SVN довольно неинтуитивен.Git еще хуже.[саркастическое предположение] Это может быть потому, что разработчики, которым нравятся сложные задачи вроде параллельного контроля версий, не очень заинтересованы в создании хорошего пользовательского интерфейса.[/саркастическое предположение]

Сторонники SVN считают, что им не нужна распределенная система контроля версий. Я тоже так думал. Но теперь, когда мы используем исключительно Git, я в это верю.Теперь контроль версий работает для меня И команды / проекта, а не просто для проекта.Когда мне нужна ветка, я ветвлюсь.Иногда это ветка, у которой есть соответствующая ветка на сервере, а иногда ее нет.Не говоря уже обо всех других преимуществах, с которыми мне придется ознакомиться (отчасти благодаря загадочному и абсурдному отсутствию пользовательского интерфейса, которым является современная система контроля версий).

Почему я думаю, что Subversion лучше, чем Git (по крайней мере, для проектов, над которыми я работаю), в основном из-за его удобства использования и более простого рабочего процесса:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow