Что делает SVN лучше, чем Git? [закрыто]

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

Менее распространено то, что недавно внедренная технология действительно, явно превосходит существующие варианты.

Это на самом деле случай с системами контроля версий (VCS), в частности, централизованный VCS ( CVS и SVN ) по сравнению с распределенным VCS ( Git и Mercurial )

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

Я могу придумать ряд преимуществ Git over Subversion (и которые в большинстве своем абстрактны для преимуществ распределенных по централизованным VCS), но я не могу придумать один пример contra - некоторая задача (это актуально и возникает в обычный рабочий процесс программистов), что Subversion делает лучше, чем Git.

Вывод only , который я сделал из этого, состоит в том, что у меня нет данных - не то, что Git лучше и т. д.

Я предполагаю, что такие встречные примеры существуют, следовательно, этот вопрос.

284 голоса | спросил 4 revs, 3 users 59%
doug
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

20 ответов


203

Subversion - это центральный репозиторий

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

Subversion - это обычная мудрость

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

Subversion делает это одним способом, а ничего больше

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

Другие преимущества:

  • SVN поддерживает пустые каталоги
  • SVN имеет лучшую поддержку Windows
  • SVN может проверить /клонировать поддеревье
  • SVN поддерживает эксклюзивное управление доступом svn lock, которое полезно для файлов с жестким слиянием
  • SVN более легко поддерживает двоичные файлы и большие файлы (и не требует копирования старых версий везде).
  • Добавление фиксации предполагает значительно меньшее количество шагов, поскольку нет никакого pull /push, и ваши локальные изменения всегда неявно переустанавливаются на svn update.
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
128

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

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
51

Я могу думать о трех. Во-первых, это немного легче понять, особенно для не-разработчиков. Концептуально это намного проще, чем параметры DCVS . Вторая - зрелость, особенно TortoiseSVN в Windows. TortoiseHg догоняет быстро. В-третьих, природа зверя - всего лишь образ файловой системы, где вы можете проверять вещи с любого уровня дерева - может оказаться весьма удобной в некоторых сценариях - например, управление версиями разнообразных конфигурационных файлов на десятках серверов без десятков репозиториев.

Это не означает, что мы не продвигаем все разработки до Mercurial.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
31
  • Репозитории SVN более управляемы с точки зрения менеджера и администратора ( ACL + методы проверки подлинности + hotcopy + mirror + dumps)
  • SVN * -хики проще реализовать и поддерживать
  • svn:external обладает большей мощностью и гибкостью, чем подмодули.
  • Деревья репозитория на основе файловой системы проще в использовании, чем монолитные репозитории с логическим разделением
  • У SVN больше разных клиентских инструментов
  • SVN имеет сторонние веб-интерфейсы, гораздо лучше, чем Git's
  • SVN не разрушает ваш мозг.
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
24

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

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

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
22

Мои причины:

  • зрелость - как сервер, так и инструменты (например, TortoiseSVN)
  • простота - меньше шагов, фиксация - это фиксация. DVCS, такие как Git и Mercurial, включают фиксацию, затем нажмите.
  • двоичная обработка - SVN обрабатывает двоичные исполняемые файлы и изображения лучше, чем Git /Hg. Особенно полезно для .NET-проектов, так как мне нравится проверять связанные с построением инструменты в исходном управлении.
  • нумерация - SVN имеет читаемую схему нумерации фиксации, используя только цифры - проще отслеживать номера версий. Git и Hg делают это совершенно по-другому.
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
22

Я ценю, что вы ищете хорошую информацию, но этот вопрос просто приглашает: «Я думаю, что Git так много побеждает, и svn suxorz!» ответы.

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

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

То, что я пытаюсь сделать, состоит в том, что если вы небольшая команда, работающая в среде с небольшим проектом, и вы уже знакомы с SVN, то используйте ее. Это, безусловно, лучше, чем CVS или (содрогаться) SourceSafe , и это не требует меня больше, чем пять минут, чтобы создать репозиторий. Гит иногда может быть переполнен.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
20

Это все относительное, и, как сказал maple_shaft, если вы работаете для вас, не меняйте!

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
18

Юзабилити. Это не заслуга Subversion, а скорее TortoiseSVN .. TortoiseGit существует, но ему еще предстоит пройти долгий путь, чтобы соответствовать TortoiseSVN.

Если вы спросите, что Git делает лучше SVN, я бы ответил GitHub . Забавно, как сторонние инструменты имеют такую ​​огромную разницу.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
16

Если вам не нужно встраивать и объединять , SVN (с TortoiseSVN в Windows) очень легко понять и использовать. Git слишком сложна для простых случаев, так как она пытается облегчить разветвление /слияние.

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
14

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

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

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
11

На работе я не смог переключить разработчиков из SVN на любой DVCS по двум причинам:

  • Частичные проверки (например, только три папки с разных глубин в дереве проектов)
  • Блокировка файлов (отчеты в двоичном формате)
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
8
  • Смысл безопасности при выполнении 'svn commit'. Поскольку коммиты идут на сервер, нет никакой возможной ошибки, которую я могу сделать, которая сотрет мои изменения после того, как они будут совершены. В git коммиты локальны, поэтому до тех пор, пока я не надавливаю, блуждающий «rm -rf» и все кончено.
  • Записи заверяются. По умолчанию в git я могу сказать, что я совершаю как никто.
  • Меньше команд, чтобы учиться для повседневного использования. 'svn checkout', 'svn up' и 'svn commit' доставят вам довольно далеко.
  • Общие кассы работают намного приятнее. Когда вы переходите к фиксации, он запрашивает ваше имя пользователя /пароль, вам не нужно забывать передавать определенные аргументы командной строки. Иногда на работе у нас есть совместно используемая машина с общим svn checkout какого-то проекта. Кто-то может сказать: «Боб, ты можешь смотреть на это на этой машине», и он может, и он может совершать свои изменения в качестве своего пользователя без каких-либо взломов.
  • Расположение репозитория. Вы можете создать зонтичный проект и подпроекты и выбрать, что проверить, когда.
  • Номера версий увеличивают целые числа.
  • Предназначен для рабочего процесса центрального хранилища.
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
6

Другие люди опубликовали неплохие ответы, но как насчет Разрешений? Используя Subversion через SSH, вы можете создать отдельную учетную запись на своем сервере для SVN. Разным разработчикам может быть предоставлен другой доступ к различным частям репозитория. Может ли GIT это сделать? Я думаю, что есть гитолит, но он просто не кажется мне гибким или надежным, и я не знаю никого, кто его использует.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
5

Скорость. Иногда требуется 10 или 15 минут, чтобы клонировать большой репозиторий git, в то время как хранилище subversion аналогичного размера занимает пару минут, чтобы проверить.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
4

Я размещаю это как ответ, а не комментарий.

Я признаю, что DVCS сейчас довольно тренда, но я постараюсь объяснить, почему.

DVCS лучше, потому что, как говорили многие люди, «это то, как мы должны были работать с самого начала». Это правда, вы можете сделать с DVCS то, что вы использовали с SVN, таким образом, что делает SVN устаревшим.

Однако не каждый программный проект так же хорош, как и он:

  • Долгосрочный проект получил много преимуществ от DVCS, поскольку он использует меньше накладных расходов, позволяет значительно улучшить управление (разветвление и т. д.) и значительно поддерживается хостами, такими как код google и github.

  • Эти проекты не единственные, есть проекты другого типа, которые разрабатываются в компаниях без какой-либо помощи из внешнего мира или Интернета: все делается внутренне и часто на короткий срок. Хороший пример: видеоигра. Код быстро развивается.

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

  • Разработчики имеют машины, принадлежащие компании, и это может быстро измениться. Настройка репо - это потеря времени.
  • Если у этих парней нет собственной машины, они с меньшей вероятностью будут работать с одним и тем же исходным кодом /частью проекта. Плюс один для централизованных данных.
  • скорость сети и большие деньги позволяют использовать централизованный сервер, который имеет дело со всем SVN, это плохая практика, но создаются резервные копии и т. д.
  • SVN - это просто simpleer для использования, даже если это неправильный способ: синхронизация файлов с одноранговыми узлами без избыточности - это не простая проблема, а «сделать это правильно» просто не удается сделать это вовремя если вы всегда хотите, чтобы это было идеально.

Подумайте о машине игровой индустрии и о том, как SVN - экономия времени; люди больше общаются над этими проектами, потому что игры посвящены повторяющемуся программированию и адаптивному коду: нет ничего сложного в коде, но это нужно сделать правильно, как можно скорее. Программисты наняты, они компилируют свою часть, компилируют ее, немного тестируют, совершают, делают, игровые тестеры будут иметь дело с остальными.

DVCS созданы для Интернета и для очень сложного проекта. SVN предназначены для небольших, краткосрочных, сложных командных проектов. Вам не нужно многому научиться из SVN, это почти FTP с немым отличием.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
3

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

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

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

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

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

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

Наконец, я также обнаружил, что совместная работа с использованием «горячей» разработки библиотеки под Svn (с использованием CI & test-driven) позволяет достичь скоординированной разработки, которую трудно достичь с помощью более распределенной и слабо связанной команды .

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
2

Ниже приведены две причины, по которым я все еще живу с SVN.

  1. Кривая обучения. SVN проще, чем Git, даже настройка (сервер или клиент), удобство и команды.
  2. Лучшие серверные пакеты, такие как Subversion Edge , VisualSVN , uberSVN и т. д.
ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
1

Сейчас есть две основные тенденции в управлении версиями; Распространение и интеграция .

Git отлично справляется с децентрализацией.

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

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

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00
-1

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

Редактирование сообщений журнала по факту часто очень полезно. Помимо исправления ошибки или упущения в сообщении журнала, он позволяет делать такие вещи, как обновление сообщения журнала, для ссылки на фиксацию future (например, ревизия, которая исправляет ошибку или завершает работы, внесенные в текущую редакцию).

Между прочим, нет никакой опасности потерять информацию. Перехватчики pre-revprop-change и post-revprop-change могут сохранять историю старых сообщений, если вы действительно обеспокоены, или отправлять электронные письма с помощью diff-сообщения журнала (это чаще встречается на самом деле), так что есть аудита.

ответил spectre 22 MarpmSat, 22 Mar 2014 16:51:00 +04002014-03-22T16:51:00+04:0004 2014, 16:51:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132