Я использовал Subversion в течение нескольких лет и после использования SourceSafe, мне просто нравится Subversion. В сочетании с TortoiseSVN я не могу себе представить, как это может быть лучше.
Тем не менее растет число разработчиков, утверждающих, что Subversion имеет проблемы и что мы должны перейти к новой породе распределенных систем управления версиями, таких как Git.
Как Git улучшает Subversion?
Git не лучше, чем Subversion. Но также не хуже. Это другое.
Ключевое отличие состоит в том, что оно децентрализовано. Представьте, что вы разработчик на дороге, вы развиваетесь на своем ноутбуке, и вы хотите иметь контроль источника, чтобы вы могли вернуться через 3 часа.
С Subversion у вас есть проблема: репозиторий SVN может находиться в недоступном для вас месте (в вашей компании, и на данный момент у вас нет интернета), вы не можете совершить. Если вы хотите сделать копию своего кода, вы должны буквально скопировать/вставить его.
С Git у вас нет этой проблемы. Ваша локальная копия - это репозиторий, и вы можете взять на себя обязательство и получить все преимущества контроля источника. Когда вы восстановите подключение к основному репозиторию, вы можете совершить против него.
Сначала это выглядит хорошо, но просто имейте в виду дополнительную сложность этого подхода.
Git похоже, "новая, блестящая, крутая" вещь. Это ни в коем случае не плохо (есть причина, по которой Линус написал это для развития ядра Linux в конце концов), но я чувствую, что многие люди прыгают на поезде "Распределенный источник" только потому, что он новый и написан Линусом Торвальдсом, зная, почему/если это лучше.
Subversion имеет проблемы, но также выполняет Git, Mercurial, CVS, TFS или что-то еще.
Изменить: Итак, этот ответ теперь год назад и все еще генерирует много оборотов, поэтому я подумал, что добавлю еще несколько объяснений. В прошлом году с момента написания этой статьи, Git получил большой импульс и поддержку, особенно потому, что такие сайты, как GitHub, действительно взлетели. Я использую как Git, так и Subversion в настоящее время, и я хотел бы поделиться личным прозрением.
Прежде всего, Git может быть действительно запутанным сначала при децентрализации. Что такое пульт? и Как правильно настроить исходный репозиторий? это два вопроса, которые возникают в начале, особенно по сравнению с простыми "svnadmin create" SVN, Git "git init" могут принимать параметры --bare и --shared, которые, по-видимому, являются "правильными" способами создать централизованный репозиторий. Есть причины для этого, но это добавляет сложности. Документация команды "checkout" очень сбивает с толку людей, которые меняются - "правильный" способ кажется "git clone", в то время как "git checkout", похоже, переключает ветки.
Git ДЕЙСТВИТЕЛЬНО светит, когда вы децентрализованы. У меня есть сервер дома и ноутбук на дороге, а SVN просто не работает. С SVN я не могу иметь локальный источник управления, если я не подключен к репозиторию (да, я знаю о SVK или о способах копирования репо). С Git, это режим по умолчанию. Это дополнительная команда, хотя (git commit совершает локально, тогда как Git push origin master нажимает главную ветвь на удаленный с именем "origin" ).
Как сказано выше: Git добавляет сложности. Два способа создания репозиториев, checkout vs. clone, commit and push... Вы должны знать, какие команды работают локально и какие работают с "сервером" (я предполагаю, что большинство людей по-прежнему любят центральный "мастер-репозиторий",).
Кроме того, инструментарий по-прежнему недостаточен, по крайней мере, в Windows. Да, есть Visual Studio AddIn, но я все еще использую Git bash с msysgit.
У SVN есть то преимущество, что его намного проще изучить: есть ваш репозиторий, все изменения к нему, если вы знаете, как создавать, фиксировать и проверять, и вы готовы к работе, и можете пикап, например, ветвление, обновление и т.д. далее.
Git имеет то преимущество, что MUCH лучше подходит, если некоторые разработчики не всегда подключены к главному репозиторию. Кроме того, он намного быстрее, чем SVN. И из того, что я слышу, поддержка ветвления и слияния намного лучше (что и следовало ожидать, поскольку это основные причины, по которым она была написана).
Это также объясняет, почему в Интернете так много шума, так как Git отлично подходит для проектов с открытым исходным кодом: просто вилка, сделайте изменения в своей собственной вилке, а затем попросите оригинального разработчика проекта потянуть изменения. С Git это просто работает. На самом деле, попробуйте на Github, это волшебство.
То, что я также вижу, - это Git -SVN Bridges: центральный репозиторий - это репо Subversion, но разработчики локально работают с Git, а затем мост переносит их изменения в SVN.
Но даже с этим длинным дополнением я все еще придерживаюсь своего основного сообщения: Git не лучше или хуже, он просто другой. Если у вас есть необходимость в "Offline Source Control" и готовность потратить дополнительное время на изучение, это фантастично. Но если у вас есть строго централизованный контроль над версиями и/или пытаются внедрить Source Control в первую очередь, потому что ваши сотрудники не заинтересованы, то простота и отличная оснастка (по крайней мере, в Windows) SVN-блеска.
С помощью Git вы можете делать практически все офлайн, потому что у каждого свой репозиторий.
Создание ветвей и объединение ветвей очень просто.
Даже если у вас нет прав на реализацию проекта, вы все равно можете иметь свой собственный репозиторий в Интернете и публиковать "push-запросы" для ваших патчей. Все, кому нравятся ваши патчи, могут привлечь их в свой проект, включая официальных сопровождающих.
Это тривиально, чтобы развить проект, изменить его и продолжать слияние в исправлениях из ветки HEAD.
Git работает для разработчиков ядра Linux. Это означает, что это действительно быстро (это должно быть) и масштабируется до тысяч участников. Git также использует меньше места (в 30 раз меньше места для репозитория Mozilla).
Git очень гибкий, очень TIMTOWTDI (Существует несколько способов сделать это). Вы можете использовать любой рабочий процесс, который хотите, и Git будет поддерживать его.
Наконец, GitHub, отличный сайт для размещения репозиториев Git.
Недостатки Git:
Другие ответы хорошо прояснили основные функции Git (что отлично). Но также существует так много способов, которыми Git ведет себя лучше и помогает сохранить жизнь более разумной. Вот некоторые из мелочей:
" Почему Git лучше X" описывает различные плюсы и минусы Git против других SCM.
Коротко:
Есть некоторые недостатки:
В самом упрощенном использовании Subversion и Git почти одинаковы. Между ними нет большой разницы:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
и
git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Где Git действительно сияет, веткится и работает с другими людьми.
Google Tech Talk: Линус Торвальдс на git
http://www.youtube.com/watch?v=4XpnKHJAok8
Страница сравнения Git Wiki
Ну, он раздался. Тесты показывают, что он значительно быстрее (учитывая его распределенный характер, операции, такие как diff и logs, все локальны, поэтому, конечно, в этом случае он невероятно быстрее), а рабочие папки меньше (что все еще вызывает у меня мысли).
Когда вы работаете над подрывной деятельностью или какой-либо другой системой контроля версий клиент/сервер, вы фактически создаете рабочие копии на своем компьютере, проверяя изменения. Это представляет собой моментальный снимок во времени, как выглядит хранилище. Вы обновляете свою рабочую копию с помощью обновлений и обновляете репозиторий через фиксации.
С распределенным контролем версий у вас нет моментального снимка, а всего кода. Хотите сделать разницу с 3-месячной версией? Нет проблем, 3-месячная версия все еще находится на вашем компьютере. Это не только означает, что все быстрее, но если вы отключены от центрального сервера, вы все равно можете выполнять многие операции, к которым вы привыкли. Другими словами, у вас есть не только снимок данной версии, но и вся база кода.
Вы думаете, что Git займет кучу места на вашем жестком диске, но из пары тестов, которые я видел, на самом деле это меньше. Не спрашивай меня, как. Я имею в виду, он был построен Линусом, он знает кое-что о файловых системах, я думаю.
Основные моменты, которые мне нравятся в DVCS, таковы:
Основной причиной относительно большого проекта является улучшенная связь, созданная точкой 3. Другие - хорошие бонусы.
Самое смешное: Я принимаю проекты в Subversion Repos, но обращаюсь к ним через команду Git Clone.
Пожалуйста, прочитайте Разработайте Git в проекте Google Code
Хотя Google Code изначально говорит Subversion вы можете легко использовать Gitво время разработки. Поиск "gitsvn" предполагает, что эта практика широко распространены, и мы тоже поощряем вас экспериментировать с ним.
Использование Git в репозитории Svn дает мне преимущества:
backup/public для других, чтобы проверитьВсе ответы здесь, как и ожидалось, ориентированы на программистов, однако что произойдет, если ваша компания использует контроль версий вне исходного кода? Существует множество документов, которые не являются исходным кодом, которые имеют преимущество в управлении версиями, и должны жить близко к коду, а не к другой CMS. Большинство программистов не работают изолированно - мы работаем для компаний как часть команды.
С учетом этого сравните простоту использования, как для клиентского инструмента, так и для обучения, между Subversion и git. Я не вижу сценария, когда какая-либо распределенная система контроля версий будет проще использовать или объяснять не-программисту. Мне бы хотелось, чтобы меня доказали неправильно, потому что тогда я смогу оценить git и на самом деле надеюсь, что он будет принят людьми, нуждающимися в контроле версий, которые не являются программистами.
Даже тогда, если его спросит руководство, почему мы должны перейти от централизованной к распределенной системе контроля версий, мне было бы трудно дать честный ответ, потому что он нам не нужен.
Отказ от ответственности: меня заинтересовал Subversion на раннем этапе (около v0.29), поэтому, очевидно, я предвзятый, но компании, с которыми я работал с тех пор, получают выгоду от моего энтузиазма, потому что я поощрял и поддерживал его использование, Я подозреваю, что так происходит с большинством компаний-разработчиков программного обеспечения. С таким большим количеством программистов, которые прыгают на победителя git, интересно, сколько компаний упустит преимущества использования контроля версий за пределами исходного кода? Даже если у вас есть отдельные системы для разных команд, вы упускаете некоторые из преимуществ, таких как (унифицированная) интеграция отслеживания проблем, в то же время увеличивая требования к обслуживанию, оборудованию и обучению.
Subversion по-прежнему является гораздо более используемой системой управления версиями, что означает, что она имеет лучшую поддержку инструмента. Вы найдете зрелые плагины SVN для почти любой IDE, и есть хорошие расширения для проводников (например, TurtoiseSVN). Кроме этого, я должен согласиться с Michael: Git не лучше или хуже, чем Subversion, он отличается.
Одна из вещей, которые меня раздражают, заключается в том, что она помещает свою собственную папку в каждую директорию проекта, тогда как git помещает только один из корневого каталога. Это не такая уж большая сделка, но такие мелочи складываются.
Конечно, SubVersion имеет Tortoise, который [обычно] очень приятный.
Дэвид Ричардс Блог WANdisco в Subversion/ GIT
Появление GIT принесло с собой породу фундаменталистов DVCS - "Gitterons", которые думают, что ничего, кроме GIT, - это дерьмо. Похоже, что Gitterons считают, что разработка программного обеспечения происходит на их собственном острове и часто забывают, что большинство организаций не используют исключительно программистов-разработчиков. Это нормально, но не то, как думает остальная часть рынка, и я рад это доказать: GIT, при последнем взгляде было менее трех процентов рынка, а Subversion - в районе пяти миллионов пользователей и около половина всего рынка.
Проблема, которую мы видели, заключалась в том, что Gitterons стреляли (дешевые) выстрелы в Subversion. Твиты вроде "Subversion - это [медленный/дерьмовый/ограничительный/не пахнет хорошо/смотрит на меня смешным способом), и теперь у меня есть GIT и [все работает в моей жизни/моя жена забеременела/у меня есть подруга после 30 лет попыток/я выиграл шесть раз подряд на столе блэкджека]. Вы получаете картину.
Git также делает разветвление и слияние очень легким. Subversion 1.5 просто добавил отслеживание слияния, но Git все еще лучше. С Git ветвление очень быстро и дешево. Это делает создание ветки для каждой новой функции более выполнимой. Ох и Git репозитории очень эффективны с объемом памяти по сравнению с Subversion.
Все о простоте использования/шагах, необходимых для чего-то.
Если я разрабатываю один проект на своем ПК/ноутбуке, git лучше, потому что его гораздо проще настроить и использовать. Вам не нужен сервер, и вам не нужно постоянно вводить URL-адрес репозитория при слиянии.
Если бы это было всего 2 человека, я бы сказал, что git также проще, потому что вы можете просто нажать и потянуть друг друга.
Как только вы выйдете за рамки этого, я бы пошел на подрывную деятельность, потому что в этот момент вам нужно настроить выделенный сервер или местоположение.
Вы можете сделать это с помощью git как с SVN, но преимущества git перевешиваются необходимостью делать дополнительные шаги для синхронизации с центральным сервером. В SVN вы просто совершаете. В git вам нужно выполнить git commit, затем git push. Дополнительный шаг раздражает просто потому, что вы так много делаете.
SVN также имеет преимущества лучших инструментов графического интерфейса, однако экосистема git, похоже, быстро догоняет, поэтому я не буду беспокоиться об этом в долгосрочной перспективе.
У Easy 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 - это просто VCS.
Я думаю, что Subversion в порядке.. пока вы не начнете слияние.. или ничего не делаете.. или что-либо делать. Subversion считает сложным (например, делать запросы, чтобы выяснить, какие ветки испортились с определенным файлом, где изменение действительно происходит из, обнаружение копий и паст и т.д.)...
Я не согласен с выигрышным ответом, говоря, что основное преимущество GIT - работа в автономном режиме - это, безусловно, полезно, но это больше похоже на дополнительный вариант для моего использования. SVK также может работать в автономном режиме, но для меня нет вопроса, какой из них нужно вкладывать в мое учебное время).
Это просто невероятно мощное и быстрое и, как следствие, привыкание к концепциям - очень полезно (да, в этом смысле: удобство для пользователя).
Подробнее об истории слияния см. это: Используя git -svn (или аналогичный) * just *, чтобы помочь с слиянием svn?
Благодаря тому, что ему не нужно постоянно связываться с центральным сервером, почти каждая команда работает менее чем за секунду (очевидно, что git push/pull/fetch медленнее просто потому, что они должны активировать SSH-соединения). Ветвление намного проще (одна простая команда для ветвления, одна простая команда для объединения)
Мне очень нравится управлять локальными ветвями моего исходного кода в Git без мутирования воды в центральном хранилище. Во многих случаях я могу проверить код с сервера Subversion и запустить локальный репозиторий Git, чтобы это сделать. Также замечательно, что инициализация репозитория Git не загрязняет файловую систему кучей раздражающих папок .svn везде.
И что касается поддержки инструментов Windows, TortoiseGit очень хорошо справляется с основами, но я все же предпочитаю командную строку, если я не хочу просматривать журнал. Мне очень нравится, как помогает Tortoise { Git | SVN} при чтении журналов фиксации.
Это неправильный вопрос. Слишком легко сосредоточиться на бородавках git и сформулировать аргумент о том, почему подрывная деятельность якобы лучше, по крайней мере для некоторых случаев использования. Тот факт, что git изначально был разработан как низкоуровневый конструктор для управления версиями и имеет интерфейс, ориентированный на Linux, ориентированный на барокко, облегчает для священных войн получение тяги и воспринимаемой легитимности. git сторонники бьют барабан с миллионами рабочих возможностей, которые svn ребята провозглашают ненужными. Довольно скоро все дебаты создаются как централизованные и распределенные, что отвечает интересам сообщества разработчиков svn предприятия. Эти компании, которые обычно выпускают самые убедительные статьи о превосходстве подрывной деятельности на предприятии, зависят от предполагаемой незащищенности git и готовности предприятия svn к долгосрочному успеху своих продуктов.
Но вот проблема: Subversion - это архитектурный тупик.
В то время как вы можете взять git и легко скомпилировать централизованную замену subversion, несмотря на то, что около два с половиной раза svn никогда не получал даже базового отслеживания слияния, работающего где угодно, а также в git. Одной из основных причин этого является дизайнерское решение сделать ветки такими же, как каталоги. Я не знаю, почему они пошли так, изначально, это, безусловно, делает частичные проверки очень простыми. К сожалению, это также делает невозможным отслеживание истории. Теперь очевидно, что вы должны использовать соглашения компоновки репозитория subversion для разделения ветвей из обычных каталогов, а svn использует некоторые эвристики, чтобы заставить вещи работать в повседневных случаях использования. Но все это просто документирование очень плохого и ограниченного проектного решения низкого уровня. Возможность сделать репозиторий-мудрый diff (а не разницу по каталогам) является базовой и критической функциональностью для системы управления версиями и значительно упрощает внутренние функции, что позволяет создавать более интеллектуальные и полезные функции поверх нее. Вы можете видеть, сколько усилий было затрачено на расширение подрывной деятельности, и тем не менее, насколько это далеко от текущего урожая современных VCS с точки зрения фундаментальных операций, таких как разрешение слияния.
Теперь вот мой сердечный и агностический совет для тех, кто все еще полагает, что Subversion достаточно хорош для обозримого будущего:
Subversion никогда не сможет догнать новые породы VCS, которые узнали из ошибок RCS и CVS; это техническая невозможность, если они не изменят модель репозитория с нуля, но тогда это не будет svn? Независимо от того, насколько вы думаете, что у вас нет возможностей современного VCS, ваше невежество не защитит вас от подводных ловушек Subversion, многие из которых являются ситуациями, которые невозможно или легко разрешить в других системах.
Чрезвычайно редко, что техническая неполноценность решения настолько ясна, как и с svn, конечно, я бы никогда не сформулировал такое мнение о win-vs-linux или emacs-vs-vi, но в этом случае это так понятно, и контроль источника является таким фундаментальным инструментом в арсенале разработчика, что я считаю, что это должно быть сформулировано однозначно. Независимо от требования использовать svn по организационным причинам, я умоляю всех пользователей svn не допустить, чтобы их логический разум создал ложное убеждение в том, что более современные VCS являются полезными только для крупных проектов с открытым исходным кодом. Независимо от характера вашей разработки, если вы программист, вы будете более эффективным программистом, если научитесь использовать более совершенные VCS, будь то Git, Mercurial, Darcs или многие другие.
Subversion очень проста в использовании. Я никогда не находил в последние годы проблему или что-то не работает должным образом. Также есть много отличных инструментов графического интерфейса, и поддержка SVN-интеграции большая.
С Git вы получаете более гибкую VCS. Вы можете использовать его так же, как SVN, с удаленным репозиторием, где вы совершаете все изменения. Но вы также можете использовать его в основном в автономном режиме и только время от времени вносить изменения в удаленный репозиторий. Но Git более сложный и имеет более крутую кривую обучения. Я впервые попал в неправильные ветки, создавая ветки косвенно или получая сообщения об ошибках с небольшой информацией об ошибке и где я должен искать в Google, чтобы получить более подробную информацию. Некоторые простые вещи, такие как замещение маркеров ($ Id $), не работают, но Git имеет очень гибкий механизм фильтрации и перехвата для объединения собственных скриптов, поэтому вы получаете все необходимое и многое другое, но для этого требуется больше времени и чтения документация;)
Если вы работаете в основном в автономном режиме с локальным репозиторием, у вас нет резервной копии, если что-то потеряно на вашем локальном компьютере. С SVN вы в основном работаете с удаленным репозиторием, который одновременно является резервным копированием на другом сервере... Git может работать одинаково, но это не главная цель Linus иметь что-то вроде SVN2. Он был разработан для разработчиков ядра Linux и потребностей распределенной системы управления версиями.
Является ли Git лучше, чем SVN? Разработчики, которым нужна только история версий и механизм резервного копирования, имеют хорошую и легкую жизнь с SVN. Разработчики, работающие часто с веткими, одновременно тестируя больше версий или работая в основном в автономном режиме, могут воспользоваться функциями Git. Есть некоторые очень полезные функции, такие как stashing, не найденные с SVN, которые могут облегчить жизнь. Но с другой стороны не всем людям нужны все возможности. Поэтому я не вижу мертвых SVN.
Git требуется более качественная документация, и отчет об ошибках должен быть более полезным. Также существующие полезные графические интерфейсы встречаются редко. На этот раз я нашел только 1 GUI для Linux с поддержкой большинства Git функций (git -cola). Интеграция Eclipse работает, но ее официальная версия не выпущена, и нет официального сайта обновлений (только на каком-то внешнем сайте обновлений с периодическими сборками из trunk http://www.jgit.org/updates) Таким образом, наиболее предпочтительным способом использования Git в наши дни является командная строка.
Eric Sink от SourceGear написал ряд статей о различиях между распределенными и нераспределенными системами управления версиями. Он сравнивает плюсы и минусы самых популярных систем управления версиями. Очень интересное чтение.
Статьи можно найти в своем блоге www.ericsink.com:
Для людей, которые ищут хороший графический интерфейс Git, Syntevo SmartGit может быть хорошим решением. Я думаю, что он проприетарный, но бесплатный для некоммерческого использования, работает на Windows/Mac/Linux и даже поддерживает SVN с использованием своего рода git -svn bridge.
Во-первых, одновременное управление версиями кажется простой проблемой для решения. Это совсем не так. В любом случае...
SVN совершенно не интуитивно понятен. Git еще хуже. [sarcastic-speculation] Возможно, это связано с тем, что разработчики, которые, как жесткие проблемы, такие как параллельное управление версиями, не очень заинтересованы в создании хорошего пользовательского интерфейса. [/Саркастичное-предположение]
Сторонники SVN считают, что им не нужна распределенная система контроля версий. Я тоже это думал. Но теперь, когда мы используем Git исключительно, я сторонник. Теперь контроль версий работает для меня И команды/проекта, а не просто для работы над проектом. Когда мне нужна ветка, я ветку. Иногда это ветка, которая имеет соответствующую ветвь на сервере, а иногда и нет. Не говоря уже обо всех других преимуществах, которые мне нужно будет изучить (отчасти благодаря таинственному и абсурдному отсутствию пользовательского интерфейса, который является современной системой управления версиями).
Git в Windows довольно хорошо поддерживается.
Посмотрите GitExtensions = http://code.google.com/p/gitextensions/
и руководство для лучшего использования Windows Git.
http://subversion.wandisco.com/component/content/article/1/40.html
Я думаю, что достаточно безопасно сказать, что среди разработчиков SVN Vs. Аргумент Git уже давно разразился, и каждый, у кого есть собственный взгляд, лучше. Это было даже затронуто в вопросах во время нашего Webinar on Subversion в 2010 году и на последующий период.
Хайрам Райт, наш директор Open Source и президент корпорации Subversion, обсуждают различия между Subversion и Git, а также другие системы управления распределенной версией (DVCS).
Он также рассказывает о предстоящих изменениях в Subversion, таких как Work Copy Next Generation (WC-NG), которые, по его мнению, заставят несколько пользователей Git преобразовать обратно в Subversion.
Посмотрите его видео и сообщите нам, что вы думаете, комментируя этот блог или публикуя на наших форумах. Регистрация проста и займет всего минуту!
В последнее время я живу в мире Git, и мне это нравится для личных проектов, но я бы не смог переключить на него рабочие проекты из Subversion, учитывая изменения в мышлении, требуемые от персонала, без насущные преимущества. Кроме того, самый большой проект, который мы запускаем внутри компании, чрезвычайно зависит от svn: externals, который, как я видел до сих пор, не работает так красиво и плавно в Git.
Почему я думаю, что Subversion лучше, чем Git (по крайней мере, для проектов, над которыми я работаю), главным образом из-за его удобства использования и более простого рабочего процесса:
http://www.databasesandlife.com/why-subversion-is-better-than-git/