Конкретные причины по-прежнему использовать Subversion? [закрыто]

22

Я хочу выбрать систему контроля версий для своей компании. До сих пор я знаю, что у меня есть Git, Subversion и Mercurial.

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

version-control git svn user1179459
источник
36
Они оба работают. Важно то, будут ли они соответствовать вашим требованиям, о которых вы нам не сказали.
Мэтью Флинн
6
См. Зачем использовать SVN? Есть какие-нибудь скрытые плюсы (за GIT / Mercurial / Bazaar)? Переполнение стека.
детально
11
По какому аргументу вы исключаете Mercurial?
Мувисиэль
8
-1 для субъективной (травля ИМХО) формулировки и «В те дни я вижу, что Git используется чаще всего» - необходима цитата. Git чрезвычайно распространен в мире открытого кода, но в корпоративном пространстве он гораздо реже. Корпусу действительно нравится идея единого, центрального, авторитетного хранилища, и он очень медленно меняется. В корпоративном пространстве вы, скорее всего, увидите хороший оле CVS, чем SVN, не говоря уже о DVCS.
Кит
4
@RobinWinslow - SVN отличается от Git. Лучше подходит для одних обстоятельств и хуже подходит для других. Лично я предпочитаю DVCS в целом, и вы, очевидно, предпочитаете Git, но оба они являются субъективными мнениями. Они не бесценны, но они не принадлежат сайту, подобному этому.
Кит

Ответы:

46

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

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

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

Мейсон Уилер
источник
16
Я не совсем согласен с вашей оценкой, но я хотел бы добавить один важный момент в пользу SVN: многие люди в отрасли знакомы с SVN, но не знают достаточно Git, чтобы комфортно с ним работать. Если вся ваша команда привыкла к SVN, то переход на Git может стоить довольно дорого. (Конечно, может быть и обратное).
Иоахим Зауэр
8
Я бы проголосовал за эту дюжину раз, если бы мог. Многие люди идут с модой, но на самом деле не думают, зачем им нужен распределенный контроль версий.
Эйфорическая
21
@Euphoric: Я точно знаю, почему я всегда хочу распределенный контроль исходного кода для каждого проекта. Это имеет важный побочный эффект, заключающийся в том, чтобы сделать разветвление и объединение простым, очевидным и надежным. Subversion все еще увязает в угловых случаях с ветвлением, потому что выбранная базовая модель просто усложняет ее.
Ян Худек
18
Распределенный контроль версий не является «прихотью». Это эволюция управления исходным кодом, точно так же, как параллельное управление версиями было развитием парадигмы блокировки файлов.
JesperE
6
@MichaelBorgwardt, я действительно делал это несколько раз. Это гораздо проще, чем с Subversion, тот факт, что все локально очень помогает, нет необходимости объяснять взаимодействие «клиент» и «сервер». Рабочий процесс в git или hg гораздо более естественный и интуитивно понятный (если вы держитесь подальше от хитрых битов, таких как редактирование истории).
SK-logic
19

Инструменты клиента еще не упоминались. Конечно, вы можете делать все с помощью сценария командной строки, но интеграция с графическим интерфейсом может значительно повысить производительность.

Мы работаем в основном с Visual Studio; интеграция в IDE определенно лучше с SVN, чем с Git прямо сейчас. Это может измениться в будущем, но я бы определенно учел это в вашем решении так же, как функции контроля версий.

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

njr101
источник
Это хороший момент. Я думаю, что одна из причин, по которой люди предпочитают Git, а не SVN, заключается в том, что у Git лучше инструменты CLI. Но это может быть компенсировано хорошим сторонним графическим интерфейсом SVN, таким как TortoiseSVN в Windows.
Euphoric
2
Это одна из причин, почему мы выбрали Mercurial (и TortoiseHg) вместо Git. Преимущества распределенного контроля версий и достойного инструментария и интеграции IDE.
HappyCat
15

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

И это единственный профессионал, которого я могу себе представить. Если вы действительно хотите положиться на эту функцию, вы можете использовать ее в распределенном и / или централизованном VCS Bazaar . В Git есть теги, которые могут служить цели.

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

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

Rajish
источник
1
На самом деле это спорный вопрос, git требуется только достаточно большая часть хэша, чтобы иметь возможность устранить неоднозначность, обычно достаточно чего-то ~ 6 символов, а не всего хэша.
TC1
2
На практике вы никогда не передаете git hash. Вы можете использовать любой уникальный префикс хеша, который обычно составляет 6-7 символов.
JesperE
1
@JesperE: Да, но номера выпусков SVN последовательно увеличиваются со временем, в то время как хэши Git, даже если вы их сокращаете, также могут быть случайными.
Кит Томпсон
2

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

В зависимости от ситуации это может иметь некоторые преимущества для SVN

(это также имеет некоторые большие недостатки, такие как скрытый мусор ".svn" на всем пути вверх по дереву папок).

Ричард Николс
источник
3
примечание: нет мусора .svn начиная с v1.7 - теперь все это хранится в одном месте.
gbjbaanb
Это не правильно - git позволяет вам извлекать только файлы, без истории, а также можно извлекать только части репо - отдельных файлов, если вы хотите. Это немного сложнее, чем SVN, но емкость есть.
Benubird
2

«Если у вас есть задача, которую можно выполнить за шесть часов, лучше написать инструмент, который выполняет ее за 20 минут, даже если создание инструмента занимает шесть часов?»

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

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

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

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

РЕДАКТИРОВАТЬ Преимущества GIT над SVN

  1. Выделенный сервер не требуется На самом деле, оба могут быть использованы без сервера.
  2. Может продолжить разработку даже без подключения к сети.
  3. Управление филиалом намного проще.
  4. Лучшая поддержка инструментов CI, таких как Bamboo

Кто-то упомянул инструментарий (для visual studio) как причину придерживаться SVN. http://gitscc.codeplex.com/ обеспечивает поддержку GIT для Visual Studio.

Апейрогон Прайм
источник
6
SVN делает ручки двоичные файлы лучше , чем Git или Hg.
Фальшивое имя
2
«Вы попадете в узкое место где-то в будущем, где вам в конечном итоге придется планировать миграцию с управлением версиями ...» Извините, я не могу согласиться, что это хорошая причина сделать этот шаг сегодня. Я работал над многими проектами, где этот подход приводит к усложнению ситуации, и они отменяются задолго до того, как они смогут воспользоваться этими будущими преимуществами. Иногда достаточно хорошо, достаточно хорошо. Придерживайтесь YAGNI и возьмите то, что делает работу сегодня. Позже будет достаточно времени для беспокойства о миграции. По крайней мере, у вас все еще будет проект.
njr101
2
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Я полностью не согласен с этим. Это может иметь некоторые ощутимые преимущества в некоторых обстоятельствах, но такая простая вещь, как номер версии в svn, читаемый человеком, является огромным преимуществом во многих организациях.
TZHX
1
@apeirogon - все сводится к тому, что вы собираетесь поместить в хранилище. Один из заголовков одного из основных репозиториев, с которым я работаю, составляет 11,1 ГБ! Если бы у меня было это в репозитории Git / bzr / hg, это, вероятно, заняло бы 100+ ГБ.
Фальшивое имя
1
Конечно, это связано с тем, что в этом репо полно файлов печатных плат и трехмерных моделей, которые имеют двоичный формат и не очень экономят место. Здесь рекомендации (Electronics.SE, например, для тех, кто хранит файлы PCB ddesign и т. Д.) Сильно отличаются от тех, кто хранит исходный код.
Фальшивое имя
1

будет ли какая-то конкретная причина использовать Subversion в те дни

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

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

Я этого не понимаю Но вы знаете, что? Это не важно Вам не нужно знать что-либо из этого, чтобы использовать Git.

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

Конечно, вы все еще можете использовать SVN. Вы также можете использовать Windows XP. Тем не менее, большинство пользователей, которые пробовали оба, соглашаются, что одна из альтернатив значительно превосходит их.

+1 Да понял, что это шутка. Я думаю.

Конрад Рудольф
источник
Учебник Git с гомеоморфными эндофункторами, отображающими подмногообразия гильбертова пространства? Мне нужно это прочитать! Но разве это не относится к Дарсу, который написан на Хаскеле (который, как я считаю, относится к endofunctor ) и вдохновлен квантовой механикой (отсюда и Гильбертово пространство )? Я действительно не вижу, что Git и HG имеют отношение к этим вещам.
оставлено около
@leftaroundabout Это шутка. Описание даже не точное (насколько я знаю). Это риф на многие уроки, которые начинаются с «веток git легко, как только вы это поймете ...», а затем идет сложная предметно-ориентированная метафора.
Конрад Рудольф
1
Задумывались ли вы, что все эти чрезмерно сложные уроки существуют по какой-то причине? И для чего это вообще? Я никогда не понимал навязчивую идею DVCS о ветвлении, а затем о реинтеграции ветки для каждой мелочи. Мне всегда казалось, что это решение проблемы. Реинтегрировать ветку в SVN сложно, потому что в первую очередь это действительно глупая и концептуально неправильная вещь , и я действительно не нахожу никаких аргументов, которые сводятся к тому, что «наш продукт делает неправильные вещи намного проще» очень убедительно
Мейсон Уилер
1
Что касается параллельной работы над несколькими изменениями, я признаю, что это немного болезненно, но правильное решение - стеллаж, который запланирован на следующий выпуск SVN. И в большинстве случаев, если вы работаете над несколькими изменениями одновременно (и особенно, если вы делаете это последовательно!), Это свидетельствует о более широкой проблеме, которую следует решать на уровне организации, а не с помощью новых инструменты. (См. Выше, «наш продукт позволяет делать неправильные вещи намного проще», и классическую статью Джоэла о переключении задач для человека.)
Мейсон Уилер,
3
@KonradRudolph В последних версиях SVN слияние ветвей обратно в ствол работает очень хорошо. Уже несколько лет стало неуклонно лучше, и теперь это очень хорошо.
Адам Брусс