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

голоса
393

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

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

Как Git улучшить Subversion?

Задан 03/08/2008 в 23:38
источник пользователем
На других языках...                            


30 ответов

голоса
548

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

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

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

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

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

Git кажется «новой, блестящей, холодной» вещь. Ни в коем случае не плохо (есть причина Линус написал ее для разработки ядра Linux все-таки), но я чувствую, что многие люди прыгают на поезде «Распределенная Source Control» только потому, что это новое и написано Линус Торвальдс, фактически зная, почему / если это лучше.

Subversion имеет проблемы, но так же Git, Mercurial, CVS, TFS или любой другой.

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

Прежде всего, Git может быть очень запутанным сначала при работе децентрализована. Что такое удаленное? и Как правильно настроить начальное хранилище? два вопроса, которые приходят в начале, особенно по сравнению с SVN просто «svnadmin создать», «мерзавец INIT» Git может принимать параметры --bare и --shared, которые, как представляется, «правильный» способ создания централизованного репозиторий. Есть причины для этого, но это добавляет сложности. Документация команды «проверки» сбивает с толку людей, переходящих на - «правильный» путь, кажется, «мерзавец клоном», в то время как «мерзавец контроль», кажется, для переключения ветвей.

Git действительно сияет, когда вы децентрализованные. У меня есть сервер на дому и ноутбук на дороге, и SVN просто не работает хорошо здесь. С SVN, я не могу контролировать локальный источник, если я не подключен к хранилищу (Да, я знаю о СВК или о том, чтобы скопировать репозиторий). С Git, это режим по умолчанию в любом случае. Это дополнительная команда, хотя (мерзавец фиксации совершает локально, в то время как мерзавец мастер толчок происхождения толкает мастер ветвь к удаленному имени «происхождение»).

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

Кроме того, инструмент по-прежнему недостаточно, по крайней мере, на Windows. Да, есть Visual Studio AddIn, но я до сих пор используют Git Баш с msysgit.

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

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

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

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

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

Ответил 03/08/2008 в 23:45
источник пользователем

голоса
145

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

Создание ветвей и слияние между ветвями очень легко.

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

Это тривиальное раскошелиться проектом, модифицировать его и сохранить слияние в исправлениях от головы ветви.

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

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

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

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

  • это гораздо труднее учиться, потому что Git имеет больше понятий и больше команд.
  • изменения не имеют номера версий, как и в подрывной деятельности
  • многие команды Git являются загадочными, и сообщения об ошибках очень пользователем недружественный
  • ему не хватает хорошего GUI (например, большой TortoiseSVN )
Ответил 04/08/2008 в 01:24
источник пользователем

голоса
110

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

  1. Git имеет команду «чистую». SVN отчаянно нуждается в этой команде, учитывая, как часто он будет сбрасывать лишние файлы на жестком диске.
  2. Git имеет команду «делящие». Мило.
  3. SVN создает .svn каталоги в каждой папке (Git создает только один каталог .git). Каждый скрипт , который вы пишете, и каждый Grep вы делаете, должны быть написаны , чтобы игнорировать эти папки .svn. Кроме того, необходимо всю команду ( «экспорт СВН») только , чтобы получить вменяемый копию ваших файлов.
  4. В SVN, каждый файл и папка может прийти из другого пересмотра или филиала. Во-первых, это звучит хорошо, чтобы иметь эту свободу. Но что это на самом деле означает, что есть миллион различных способов для вашей местной кассы быть полностью облажались. (Например, если «SVN переключатель» терпит неудачу на полпути, или если вы введете команду неправильно). И самое худшее: если вы когда-нибудь попасть в ситуацию, когда некоторые файлы поступают из одного места, а некоторые из них от другого, «статус СВН» покажет вам, что все нормально. Вам нужно сделать «СВН информации» на каждый файл / папке, чтобы узнать, как странные вещи. Если «статус мерзавец» говорит вам, что все в норме, то вы можете доверять, что вещи действительно являются нормальными.
  5. Вы должны сказать SVN всякий раз, когда вы перемещаете или удалить что-нибудь. Git будет просто понять это.
  6. Игнорировать семантики проще в Git. Если вы игнорируете шаблон (например, * .pyc), оно будет проигнорировано для всех подкаталогов. (Но если вы действительно хотите , чтобы игнорировать что - то только для одного каталога, вы можете). С SVN, кажется , что не существует простой способ игнорировать шаблон во всех подкаталогах.
  7. Другой вопрос, с участием игнорировать файлы. Git делает возможным иметь «частный» игнорировать настройки (с использованием файла .git / данные / исключения), которые не будут влиять на кого-либо еще.
Ответил 26/09/2008 в 01:18
источник пользователем

голоса
56

« Почему Git лучше , чем X » описываются различные преимущества и недостатки Git против других SCMs.

Кратко:

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

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

  • Там не много хороших ГПИ для нее еще. Это новое и Subversion был вокруг намного дольше, так что это естественно , так как есть несколько интерфейсов в развитии. Некоторые хорошие включают TortoiseGit и 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 действительно светит ветвится и работать с другими людьми.

Ответил 10/02/2009 в 05:18
источник пользователем

голоса
54

Google Tech Talk: Линус Торвальдс на мерзавца

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

Страница сравнения мерзавец вики

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

Ответил 03/08/2008 в 23:44
источник пользователем

голоса
26

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

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

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

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

Ответил 03/08/2008 в 23:47
источник пользователем

голоса
22

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

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

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

Ответил 04/09/2008 в 12:06
источник пользователем

голоса
15

Самое смешное: я у себя проекты в Subversion Репо, но доступ к ним с помощью команды Git Clone.

Пожалуйста , ознакомьтесь с Разрабатывать с Git на код проекта Google

Хотя Google Code изначально говорит Subversion, вы можете легко использовать Git в процессе разработки. Поиск «мерзавца СВН» предлагает эта практика широко распространена, и мы также рекомендуем вам поэкспериментировать с ним.

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

  1. Я могу работать распределен на несколько машин, и вытягивать совершал от и к ним
  2. У меня есть центральный backup/public репозиторий SVN для других , чтобы проверить
  3. И они могут свободно использовать Git для своих
Ответил 02/10/2008 в 14:05
источник пользователем

голоса
11

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

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

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

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

Ответил 13/10/2009 в 08:01
источник пользователем

голоса
9

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

Ответил 18/09/2008 в 19:44
источник пользователем

голоса
8

Дэвид Ричардс WANdisco блог на Subversion / GIT

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

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

Ответил 17/09/2010 в 19:22
источник пользователем

голоса
8

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

Конечно, SubVersion есть черепаха, которая [обычно] очень приятно.

Ответил 22/08/2008 в 16:24
источник пользователем

голоса
7

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

Ответил 09/08/2008 в 04:22
источник пользователем

голоса
6

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

Ответил 22/08/2008 в 16:19
источник пользователем

голоса
6

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

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

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

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

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

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

Ответил 04/08/2008 в 00:38
источник пользователем

голоса
5

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

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

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

Ответил 05/10/2008 в 17:52
источник пользователем

голоса
5

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

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

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

Ответил 04/08/2008 в 00:08
источник пользователем

голоса
4

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

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

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

Для получения более подробной информации о истории слияния, увидеть это: Использование ГИТ-SVN (или аналогичный) * только * , чтобы помочь с SVN слияния?

Ответил 27/07/2010 в 16:40
источник пользователем

голоса
4

Несколько ответов намекали на это, но я хочу сделать 2 очка явным:

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

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

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

Ответил 07/08/2009 в 15:59
источник пользователем

голоса
3

Это неправильный вопрос спросить. Это все слишком легко сосредоточиться на бородавки GIT и сформулировать аргумент о том, почему подрывной якобы лучше, по крайней мере, для некоторых случаев применения. Тот факт, что мерзавец был первоначально разработан как низкий уровень контроля версий набора строительства и имеет причудливую Linux-разработчик-ориентированный интерфейс облегчает священные войны, чтобы получить тягу и воспринимаемую легитимность. Git сторонники взрыва барабан с миллионами преимуществ рабочего процесса, который Svn ребята объявляют ненужными. Довольно скоро вся дискуссия оформлена как централизованная против распределенной, которая служит интересам сообщества предприятия инструмента СВН. Эти компании, которые обычно ставят из наиболее убедительных статей о превосходстве подрывной деятельности в предприятии,

Но вот проблема: Subversion является архитектурным тупиковым .

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

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

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

Крайне редко, что техническая неполноценность решения настолько четкой, как это с SVN, конечно, я никогда бы не заявить такое мнение о беспроигрышной против-Linux или Emacs-против-ви, но в данном случае это так сплошные рубки, и источником управления является настолько фундаментальным инструментом в арсенале разработчика, что я чувствую, что это должно быть указано однозначно. Вне зависимости от требования использовать SVN по организационным причинам, я умоляю все СВНА пользователей, чтобы не позволить их логическому уму построить ложное убеждение, что более современные VCSes полезны только для крупных проектов с открытым исходным кодом. Независимо от характера вашей работы в области развития, если вы программист, вы будете более эффективным программистом, если вы узнаете, как лучше использовать разработанные VCSes, будь то Git, Mercurial, Darcs, или многие другие.

Ответил 29/05/2011 в 18:30
источник пользователем

голоса
3

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

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

Ответил 10/02/2010 в 23:54
источник пользователем

голоса
3

Благодаря тому, что не нужно связываться с центральным сервером постоянно, в значительной степени каждая команда работает менее чем за секунду (очевидно мерзавцем толчка / тянуть / принести медленнее просто потому, что они должны initalise соединения SSH). Ветвление далека гораздо проще (одна простая команда филиала, одна простая команды для слияния)

Ответил 30/08/2008 в 13:01
источник пользователем

голоса
2

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

Ответил 09/03/2011 в 15:05
источник пользователем

голоса
2

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

Ответил 13/10/2009 в 14:36
источник пользователем

голоса
2

Subversion очень прост в использовании. Я никогда не находил в последние годы проблемы или что-то не работает, как ожидалось. Кроме того, есть много превосходных инструментов GUI и поддержка интеграции SVN большая.

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

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

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

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

Ответил 13/10/2009 в 14:14
источник пользователем

голоса
1

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

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

Ответил 22/10/2010 в 17:25
источник пользователем

голоса
1

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

Ответил 25/04/2010 в 22:35
источник пользователем

голоса
1

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

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

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

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

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

Ответил 10/02/2010 в 19:51
источник пользователем

голоса
1

Git в Windows, достаточно хорошо поддерживается в настоящее время.

Проверьте GitExtensions = http://code.google.com/p/gitextensions/

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

Ответил 10/02/2010 в 17:29
источник пользователем

голоса
1

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

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

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

Ответил 03/01/2010 в 13:45
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more