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

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

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

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

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

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

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

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

Subversion - это центральное хранилище

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

Subversion - это общепринятая мудрость

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

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

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

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

• SVN поддерживает пустые каталоги
• SVN имеет лучшую поддержку Windows
• SVN может проверить / клонировать поддерево
• SVN поддерживает эксклюзивный контроль доступа, svn lockкоторый полезен для трудно объединяемых файлов
• SVN легче поддерживает двоичные и большие файлы (и не требует копирования старых версий везде).
• Добавление коммита включает в себя значительно меньше шагов, так как нет никаких пул-пуш, и ваши локальные изменения всегда неявно перебазируются svn update.

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

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

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

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

• Репозитории SVN более управляемы с точки зрения менеджера и администратора ( ACL + методы аутентификации + hotcopy + зеркала + дампы)
• SVN * - крючки проще в реализации и поддержке
• svn:external имеет большую мощность и гибкость, чем подмодули
• Деревья репозитория на основе файловой системы проще в использовании, чем монолитные репозитории с логическим разделением
• У SVN больше разных клиентских инструментов
• У SVN есть сторонние используемые веб-интерфейсы, намного лучше, чем у Git
• SVN не ломает твой мозг

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

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

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

Мои причины:

• зрелость - и сервер, и инструменты (например, TortoiseSVN)
• простота - меньше шагов, коммит - это коммит. DVCS, такие как Git и Mercurial, включают коммит, затем push.
• двоичная обработка - SVN обрабатывает двоичные исполняемые файлы и изображения лучше, чем Git / Hg. Особенно полезно с проектами .NET, так как мне нравится проверять инструменты, связанные со сборкой, в системе контроля версий.
• нумерация - SVN имеет удобочитаемую схему нумерации коммитов, в которой используются только цифры - проще отслеживать номера ревизий. Git и Hg делают это совершенно по-разному.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Частичные проверки (например, только три папки разной глубины в дереве проекта)
• Блокировка файлов (отчеты в двоичном формате)

• Чувство безопасности при выполнении 'svn commit'. Поскольку коммиты отправляются на сервер, я не могу ничего сделать, чтобы стереть мои изменения после их фиксации. В git коммиты локальные, так что пока я не нажму, блуждающий 'rm -rf' и все будет кончено.
• Коммиты проходят проверку подлинности. По умолчанию в git я могу сказать, что я делаю это как любой.
• Меньше команд, чтобы учиться для повседневного использования. 'svn checkout', 'svn up' и 'svn commit' помогут вам довольно далеко.
• Общие проверки работают намного приятнее. Когда вы переходите к коммиту, он запрашивает ваше имя пользователя / пароль, вам не нужно забывать передавать определенные аргументы командной строки. Иногда на работе у нас есть общая машина с общей проверкой SVN какого-то проекта. Кто-то может сказать: «Боб, ты можешь посмотреть на это на этой машине», и он может, и он может зафиксировать свои изменения как пользователь без каких-либо ошибок.
• Расположение репозитория. Вы можете иметь общий проект и подпроекты и выбирать, что проверять, когда.
• Номера ревизий увеличивают целые числа.
• Предназначен для рабочего процесса центрального хранилища.

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

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

Я публикую это как ответ, а не как комментарий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приведены две причины, по которым я до сих пор остаюсь в SVN.

1. Кривая обучения. SVN проще, чем Git, даже настройки (сервер или клиент), удобство использования и команды.
2. Лучшие серверные пакеты, такие как Subversion Edge , VisualSVN , uberSVN и т. Д.

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

Git хорош в децентрализации.

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

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

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

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

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