Почему Git лучше Subversion?
Я использую Subversion несколько лет и после использования SourceSafe мне просто нравится Subversion. В сочетании с TortoiseSVN я не могу представить, что может быть лучше.
Тем не менее, растет число разработчиков, утверждающих, что у Subversion есть проблемы и что мы должны перейти на новое поколение распределенных систем контроля версий, таких как Git.
Как Git улучшает Subversion?
Ответы 30
Google Tech Talk: Линус Торвальдс на git
https://thewikihow.com/video_4XpnKHJAok8
Страница сравнения Git Wiki
http://git.or.cz/gitwiki/GitSvnComparsion
Этот тоже неплохой. Это от одного из коммитеров git, и он объясняет многие расширенные функции, такие как разделение больших коммитов на более мелкие. youtube.com/watch?v=j45cs5_nY2k
Мне действительно нравится это видео Линуса Торвальдса, но он подразумевает, что git является распределенным, а не централизованным, и это просто неправильно. Его можно использовать распределенно ИЛИ централизованно. У вас может быть один центральный репозиторий, который все будут использовать, как в SVN. Просто так делать не обязательно.
@MatrixForog: Я думаю, что в этом случае «децентрализованный» - это не противоположный «централизованного», а на самом деле надмножество. Это что-то вроде «мобильное» и «неподвижное» - просто потому, что что-то «мобильное», мне не кажется, что оно не может стоять на месте.
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 vs. push ... Вы должны знать, какие команды работают локально, а какие работают с «сервером» (я предполагаю, что большинству людей все еще нравится центральный «главный репозиторий» ).
Кроме того, инструментов по-прежнему недостаточно, по крайней мере, в Windows. Да, есть надстройка Visual Studio, но я все еще использую git bash с msysgit.
Преимущество SVN в том, что его НАМНОГО проще изучить: есть ваш репозиторий, все изменения в нем, если вы знаете, как создавать, фиксировать и проверять, и вы готовы к работе и можете забрать такие вещи, как ветвление, обновление и т. д. Позже. на.
У Git есть то преимущество, что он НАМНОГО лучше подходит, если некоторые разработчики не всегда подключены к главному репозиторию. Кроме того, это намного быстрее, чем SVN. И из того, что я слышал, поддержка ветвления и слияния намного лучше (чего и следовало ожидать, поскольку это основные причины, по которым она была написана).
Это также объясняет, почему он вызывает столько шума в Интернете, поскольку Git идеально подходит для проектов с открытым исходным кодом: просто создайте его, зафиксируйте свои изменения в своем собственном Fork, а затем попросите разработчика исходного проекта извлечь ваши изменения. С Git это просто работает. Действительно, попробуйте на Github, это волшебство.
Я также вижу мосты Git-SVN: центральный репозиторий - это репозиторий Subversion, но разработчики локально работают с Git, а затем мост передает свои изменения в SVN.
Но даже с этим длинным дополнением я все еще придерживаюсь своей основной идеи: Git не лучше и не хуже, это просто другое. Если у вас есть потребность в "Offline Source Control" и желание потратить дополнительное время на его изучение, это фантастика. Но если у вас есть строго централизованный контроль версий и / или вы изо всех сил пытаетесь внедрить систему контроля версий в первую очередь, потому что ваши коллеги не заинтересованы, тогда простота и отличный инструментарий (по крайней мере, в Windows) SVN сияют.
Феррари не лучше Hyundai. Но тоже не хуже. Это другое. (Что? Не смотри на МЕНЯ так ... Я что-то не так сказала?)
Нет, это не так. Ferrari непрактична, дорога, жаждет, и вам не станет лучше из пункта А в пункт Б, если вы живете в таком городе, как Нью-Йорк или Париж - я бы предпочел Hyundai для многих мест, в том числе потому, что царапина намного менее серьезна. Но каждому свое - у Ferrari тоже есть (очень немногие) преимущества ...
Распространение - не единственное различие между Subversion и Git. Это также не добавляет сложности, если вы не используете несколько репозиториев. Есть много преимущества использования Git вместо Subversion, но только несколько (в основном незначительных) недостатков. Git используется потому, что он хороший, а не блестящий.
Это вывод, если вы действительно потратили некоторое время на его изучение И если у вас есть для этого инструменты (конечно, вы должны знать все инструменты командной строки вашей CVS, но это не значит, что людям действительно нравится использовать их все время. ). Как уже было сказано, многие люди (я знаю) сказали Git = Good, потому что Линус
Я также думаю, что пропаганда GIT может принять это близко к сердцу. Вы можете забить на принципы и на то, кто этим пользуется годами, но после первого раза это отфильтровывается. Вместо абстрактных обсуждений можно было бы использовать более практическое объяснение (например, как обычно выглядит рабочий процесс).
Мой опыт работы с git - не совсем «откровение, которое изменит жизнь». Я считаю, что это отличный инструмент, когда он работает, а когда нет, тогда он кажется довольно неотшлифованным. Меня не слишком впечатлила отладка, такая как вопрос 1052882, и хотя это явно проблема RTFM: я действительно считаю git (и любые другие распределенные vcs) более сложными, чем централизованные, и я бы подумал об использовании его в централизованных средах. . Но опять же, я в основном разработчик для Windows, и инструменты для Windows все еще незрелые по сравнению с SVN.
Newflash: Системы контроля версий используют не только разработчики. Послушайте, я уверен, что git - второе пришествие, но, как администратор svn, у нас есть не разработчики, использующие его (в основном через TortoiseSVN), и я на 99% уверен, что если бы наши разработчики потребовали git, я бы поддерживал 2 системы контроля версий вместо одной. Кстати: сколько систем отслеживания ошибок и ошибок позволяют настроить несколько RCS?
Я сделал несколько дополнений, так как последние 12 месяцев действительно продали меня на Git. Это все еще очень крутая кривая обучения, и инструменты не совсем хороши в Windows, но как только узнал, что они отличные. Я не хочу казаться рекламодателем, но серия TekPub Mastering Git помогла мне понять это, особенно (для меня) сложную и критическую вещь о «Как работают Remotes».
@ Майкл: программное обеспечение отличается тем, что клонирование ничего не стоит (почти). Следовательно, только один дизайн имеет право на жизнь. Рынка, которым можно было бы делиться, практически нет, поэтому он не похож на автомобили.
Следует отметить, что Jira позволяет одновременно настраивать более одного репозитория и более одного типа репо для тех, кто заинтересован или имеет разные потребности в управлении версиями.
@hasen Только если вы преодолеете гораздо более крутую кривую обучения. Мне это очень нравится, но в средах, где вам все еще нужно продавать концепцию Source Control своим разработчикам (что в большинстве случаев означает Windows, использующую магазин для разработки), превосходный инструментарий и простота SVN просто на много миль превосходит git. Если (и это «если», а не «когда») ваши разработчики действительно используют Source Control, тогда git может начать сиять. Я бы никогда больше не стал использовать SVN, но множество людей никогда не будут использовать Git, если он не будет должным образом интегрирован в их инструменты и если они не поймут концепцию.
@Michael Stum: мем "git is hard" - полностью миф. Я считаю, что git намного проще, чем svn. Я никогда не понимал подрывной деятельности; git просто имеет смысл. Хотя я согласен с вами @, это может быть немного сложнее продать окнам, ребята.
OP, кажется, смущен Git, или я неправильно понимаю. Не существует «двух режимов создания репозиториев»: git clone ~~ svn co, git push ~~ svn ci, git commit ~~ svn add/rm/etc. Git трудно изучить, только если у вас есть предвзятые представления о том, как работает VCS. Я начал с Mercurial, перешел на git, а затем пришлось изучить SVN. Угадайте, что было сложнее всего использовать? SVN! Я начал использовать git-svn, потому что SVN ужасен. Нет ничего «правильного» в том, как svn использует термин «оформление заказа».
@sebnow Я имел в виду git init vs. git init --bare
Ах, в этом случае я бы предположил, что svnadmin create ~~ git init --bare. Единственная разница между --bare и нормальным состоит в том, что у обычного репо есть рабочий каталог (файлы извлекаются). Обычно он используется только как сервер / центральный репозиторий и может игнорироваться обычным пользователем. В этом смысле SVN также имеет «два» способа создания репозиториев; svnadmin create и svn co.
В сравнении вы анализируете только аспект распределения. Я вам скажу почему. Потому что вам нужен только код Поделиться. Git и SVN - это нечто большее, вы когда-нибудь помечали, разветвляли, объединяли, разрешали конфликты, копировали патчи между ветками? Я думаю, что ваш анализ ошибочен. В этих аспектах git - НАМНОГО мощный инструмент. Не говоря уже о вещах, которые git может, а SVN не может, таких как сжатие, отключение, исправление, перебазирование, выбор вишни и многое другое.
Вы можете просто разместить svn-сервер на своем локальном компьютере?
Когда люди говорят, что Git быстрее Subversion, сравнивают ли они локальные проверки Git с удаленными проверками Subversion? Это не похоже на честное сравнение, поскольку локальные чекины не находятся в центральном репозитории, чтобы их могли видеть другие, и не будут скопированы, если ваша локальная копия каким-то образом будет повреждена или потеряна ...
извините, но мне пришлось проголосовать против этого. Не совсем по делу, никаких хороших аргументов плюс запутанное мэшап из клонирования и проверки, которые представляют собой две совершенно разные операции!
@gilligan, согласен. Единственное, что я нашел хорошего в этом ответе, - это политкорректность («не лучше / не хуже, просто другое»).
Я собираюсь присоединиться к толпе «Git и / или Hg - это откровение, изменяющее жизнь». ИМО, git> svn, hg> svn, git == hg. Subversion использует внутреннюю модель своего репозитория с нарушенными принципами.
Git лучше svn. Объективно. Фактически. Любой, кто утверждает обратное, либо не знает git и пытается рационально избегать вложений в его изучение, либо просто иррационально относится к оценке, потому что у него есть какие-то эмоциональные связи с SVN.
Что ж, раздали. Тесты показывают, что он значительно быстрее (учитывая его распределенный характер, такие операции, как diff и журналы, все локальные, поэтому, конечно, в этом случае он невероятно быстрее), а рабочие папки меньше (что все еще поражает меня).
Когда вы работаете над Subversion или любой другой системой управления версиями клиент / сервер, вы, по сути, создаете рабочие копии на своем компьютере с помощью выписка ревизий. Это представляет собой моментальный снимок того, как выглядит репозиторий во времени. Вы обновляете свою рабочую копию через обновления, и вы обновляете репозиторий через коммиты.
При распределенном управлении версиями у вас есть не моментальный снимок, а вся кодовая база. Хотите провести сравнение с версией 3-х месячной давности? Нет проблем, версия 3-х месячной давности все еще на вашем компьютере. Это не только означает, что все происходит намного быстрее, но и если вы отключены от центрального сервера, вы все равно можете выполнять многие операции, к которым привыкли. Другими словами, у вас есть снимок не только данной ревизии, но и всей кодовой базы.
Вы могли подумать, что Git займет кучу места на вашем жестком диске, но, судя по нескольким тестам, которые я видел, на самом деле он занимает меньше места. Не спрашивайте меня, как. Я имею в виду, что он был построен Линусом, я думаю, он кое-что знает о файловых системах.
Причина, по которой Git может занимать меньше места на диске для полного репозитория, чем Subversion для простой проверки, заключается в том, что Subversion хранит «нетронутую копию», чтобы заставить работать 'svn diff' (сравнение с последней версией) ... и этот репозиторий git сжимается (и дельтаифицируется ).
Я не удивлен, что "рабочие папки" git (т.е. репозитории) меньше, чем рабочие копии svn, потому что даже репозитории svn меньше, чем рабочие копии svn.
Git и DVCS в целом отлично подходят для разработчиков, которые много пишут независимо друг от друга, потому что у каждого есть своя ветка. Однако, если вам нужно изменение от кого-то другого, он должен зафиксировать свое локальное репо, а затем он должен передать этот набор изменений вам, или вы должны получить его от нее.
Мои собственные рассуждения также заставляют меня думать, что DVCS усложняет контроль качества и управление выпусками, если вы делаете такие вещи, как централизованные выпуски. Кто-то должен нести ответственность за выполнение этого push / pull из репозитория всех остальных, разрешение любых конфликтов, которые были бы разрешены во время первоначальной фиксации ранее, затем выполнение сборки, а затем повторная синхронизация всех других разработчиков своих репозиториев.
Конечно, все это можно решить с помощью человеческих процессов; DVCS просто сломал кое-что, что было исправлено централизованным контролем версий, чтобы предоставить некоторые новые удобства.
На самом деле, если вы посмотрите, как ядро Linux или сам проект git находится под управлением, вы увидите, что Git очень хорош для рабочего процесса «один сопровождающий» (или сопровождающий + лейтенанты) с одним центральным консенсусным репозиторием. И это позволяет легко временно переключиться на кого-то другого в качестве сопровождающего.
Все дело в простоте использования / необходимых действиях.
Если я разрабатываю один проект на своем ПК / ноутбуке, git лучше, потому что его гораздо проще настроить и использовать. Вам не нужен сервер, и вам не нужно постоянно вводить URL-адреса репозитория при слиянии.
Если бы это было всего 2 человека, я бы сказал, что git также проще, потому что вы можете просто толкать и тянуть друг друга.
Однако, как только вы выйдете за рамки этого, я бы пошел на подрывную деятельность, потому что на этом этапе вам нужно настроить «выделенный» сервер или место.
Вы можете сделать это с помощью git так же хорошо, как и с SVN, но преимущества git перевешиваются необходимостью выполнения дополнительных шагов для синхронизации с центральным сервером. В SVN вы просто фиксируете. В git вам нужно сделать git commit, а затем git push. Дополнительный шаг раздражает просто потому, что вы так много делаете.
SVN также имеет преимущество улучшенных инструментов графического интерфейса, однако экосистема git, похоже, быстро догоняет, поэтому я не буду беспокоиться об этом в долгосрочной перспективе.
Отделение фиксации от публикации в Git - это, по ИМХО, преимущество, а не недостаток.
Хорошо, как бы вы оценили «простоту использования / шаги, необходимые для выполнения каких-либо действий» для SVN, когда: - создание тематической ветки для экспериментов - слияние этой ветки с другой веткой - разделение отредактированного материала в файле на их собственные меньшие коммиты - быстро проверить основную ветку, чтобы сделать небольшое исправление. ИМХО, я не понимаю, насколько проще настроить сервер SVN, чем настроить сервер git. И почему вы хотели бы отказаться от всех приятных преимуществ, которые вы получаете от легких ветвей, просто чтобы вам не «приходилось толкать отдельно».
Аргумент «тематическая ветка для экспериментов» часто выдвигается в пользу git, но, честно говоря, я никогда не видел никого, кто бы действительно делать находился в Subversion или другой системе, отличной от DVCS. Возможно, это большое дело, и мы все упускаем из виду, но из того, что я видел, 99% разработчиков (включая меня) не заботятся о тематических ветках, потому что они никогда их не используют! - Нельзя пропустить то, чего никогда не было :-). Я думаю, что если люди из DVCS собираются выдвинуть «тематические ветки» как функцию, они первый должны убедить всех, что такие вещи действительно полезны.
«Разделение отредактированного материала на более мелкие коммиты», опять же, звучит хорошо в теории. Но за последние 3 года я ни разу подумал: «О, я бы хотел сделать это», и мне трудно даже придумать гипотетическую ситуацию, в которой мне может понадобиться эта функция ... Многие из git / Сторонники DVCS просто говорят: «У нас есть X, а X - это круто», а все остальные сидят и задаются вопросом, зачем им вообще может понадобиться X
С Git вы можете делать практически все в автономном режиме, потому что у каждого есть свой репозиторий.
Создавать ветки и объединять ветки очень просто.
Даже если у вас нет прав на фиксацию проекта, вы все равно можете иметь свой собственный репозиторий в сети и публиковать «push-запросы» для своих патчей. Все, кому нравятся ваши патчи, могут включить их в свой проект, включая официальных сопровождающих.
Разветвить проект, изменить его и по-прежнему вносить исправления из ветки HEAD - тривиально.
Git работает для разработчиков ядра Linux. Это означает, что это действительно быстро (так и должно быть) и масштабируется для тысяч участников. Git также использует меньше места (до 30 раз меньше места для репозитория Mozilla).
Git очень гибкий, очень TIMTOWTDI (есть несколько способов сделать это). Вы можете использовать любой рабочий процесс, какой захотите, и Git его поддержит.
Наконец, есть GitHub, отличный сайт для размещения ваших репозиториев Git.
Недостатки Git:
- его гораздо сложнее выучить, потому что в Git больше концепций и команд.
- ревизии не имеют номеров версий, как в Subversion
- многие команды Git загадочны, а сообщения об ошибках очень недружелюбны для пользователя
- в нем отсутствует хороший графический интерфейс (например, отличный TortoiseSVN)
Хотя изучить весь Git было бы намного сложнее, основы почти идентичны. Объем обучения на самом деле не такой уж и крутой, пока вы не углубитесь в более сложные вещи, на которые SVN в любом случае просто не способен.
+1 для меня. Я думаю, что многие разработчики забывают, что git не хватает чего-то вроде TortoiseSVN, и что не только разработчики используют контроль версий. Я содрогаюсь при мысли о необходимости объяснять (и поддерживать) распределенное управление версиями нашим не разработчикам с помощью SVN | TortoiseSVN!
еще один недостаток - у вас должна быть полная копия репозитория, вы не можете работать с частичными (что имеет значение, если у вас есть огромные, как у многих корпораций)
Я люблю git, но мне потребовалось около шести месяцев ежедневного использования, чтобы действительно эффективно использовать его. При этом я использую комбинацию оболочки git (командной строки) из msysgit, git gui и gitk из msysgit и TortoiseGit. Я думаю, что TortoiseGit - это здорово, но я не понимаю, почему все больше людей не используют его. Я знаю, что разработчики msysgit ненавидят TortoiseGit по разным причинам, некоторые из которых являются идеологическими, и это может иметь какое-то отношение к этому. TortoiseGit - это хорошо хранимый секрет!
Я согласен. Использую как SVN, так и GIT (примерно с 6 месяцев). Честно говоря, я люблю git намного больше, чем SVN. Просто нужно время, чтобы этому научиться. Самый большой скачок для меня (в тот момент, когда я увидел свет: P) был, когда я наконец понял, что мне нужно перестать пытаться использовать GIT так, как работает SVN. Потом все встало на свои места;)
Git также упрощает ветвление и слияние. Subversion 1.5 только что добавила отслеживание слияния, но Git все еще лучше. С помощью Git ветвление выполняется очень быстро и дешево. Это делает более возможным создание ветки для каждой новой функции. Ох, и репозитории Git очень эффективны с пространством для хранения по сравнению с Subversion.
У Легкий Git есть хорошая страница, сравнивающая фактическое использование Git и SVN, которая даст вам представление о том, что Git может делать (или делать более легко) по сравнению с SVN. (Технически это основано на Easy Git, который представляет собой легкую оболочку поверх Git.)
Одна из вещей, которые меня раздражают в SubVersion, - это то, что она помещает свою собственную папку в каждый каталог проекта, тогда как git помещает только одну в корневой каталог. Это не имеет большого значения для который, но такие мелочи складываются.
Конечно, в SubVersion есть Tortoise, что [обычно] очень приятно.
каталоги .svn скоро исчезнут, вероятно, с v1.7
Благодаря тому, что ему не нужно постоянно связываться с центральным сервером, практически каждая команда выполняется менее чем за секунду (очевидно, что git push / pull / fetch медленнее просто потому, что им нужно инициализировать SSH-соединения). Ветвление намного проще (одна простая команда для ветвления, одна простая команда для слияния)
Главное, что мне нравится в DVCS:
- Вы можете совершать сломанные вещи. Это не имеет значения, потому что другие люди не увидят их, пока вы не опубликуете. Время публикации отличается от времени фиксации.
- Из-за этого вы можете совершать коммиты чаще.
- Вы можете объединить полную функциональность. У этой функциональности будет отдельная ветвь. Все коммиты этой ветки будут связаны с этой функциональностью. Вы можете сделать это с помощью CVCS, однако по умолчанию используется DVCS.
- Вы можете искать в своей истории (узнать, когда функция изменилась)
- Вы можете отменить извлечение, если кто-то испортит основной репозиторий, вам не нужно исправлять ошибки. Просто очистите слияние.
- Если вам нужен исходный элемент управления в любом каталоге, выполните: git init. и вы можете зафиксировать, отменить изменения и т. д.
- Это быстро (даже в Windows)
Основная причина относительно большого проекта - улучшенная коммуникация, созданная пунктом 3. Остальные - приятные бонусы.
Я думаю, что пункт №1 намеревается сказать «другие люди не увидят их, пока вы не публиковать» (или «толкните»).
+1 «Сломанные вещи можно совершать». это основная причина, по которой я рассматриваю возможность перехода на git с svn. Я всегда ненавижу, когда я на полпути к разработке тяжелого блока кода, и у меня нет страховочной системы VCS (просто потому, что мои модификации еще не работают, поэтому мне не разрешено коммитить).
Subversion по-прежнему является гораздо более используемой системой контроля версий, а это означает, что она имеет лучшую поддержку инструментов. Вы найдете зрелые плагины SVN практически для любого IDE, и есть хорошие расширения проводника (например, TurtoiseSVN). В остальном я должен согласиться с Майкл: Git не лучше и не хуже Subversion, он другой.
Но теперь, после интенсивного использования git в течение нескольких лет, я вынужден не согласиться с самим собой: Git на далеко лучше, чем Subversion. По крайней мере, однажды вы преодолеете недружелюбный синтаксис Git.
Другие ответы хорошо объяснили основные функции Git (которые великолепны). Но есть также множество способов маленький, с помощью которых Git ведет себя лучше и помогает моей жизни оставаться более разумной. Вот некоторые мелочи:
- В Git есть «чистая» команда. SVN отчаянно нуждается в этой команде, учитывая, как часто он будет выгружать лишние файлы на ваш диск.
- В Git есть команда bisect. Мило.
- SVN создает каталоги .svn в каждой отдельной папке (Git создает только каталог один .git). Каждый сценарий, который вы пишете, и каждый grep, который вы делаете, нужно будет написать так, чтобы игнорировать эти каталоги .svn. Вам также понадобится целая команда («svn export»), чтобы получить нормальную копию ваших файлов.
- В SVN каждый файл и папка могут быть из разных ревизий или веток. Поначалу такая свобода звучит неплохо. Но на самом деле это означает, что существует миллион различных способов полностью облажаться с вашей местной кассой. (например, если "svn switch" не работает на полпути, или если вы ввели неверную команду). И самое ужасное: если вы когда-нибудь попадете в ситуацию, когда некоторые из ваших файлов приходят из одного места, а некоторые из другого, «svn status» сообщит вам, что все в порядке. Вам нужно будет ввести "svn info" для каждого файла / каталога, чтобы понять, насколько странны вещи. Если «git status» сообщает вам, что все в порядке, вы можете быть уверены, что все действительно нормально.
- Вы должны сообщать SVN, когда что-то перемещаете или удаляете. Git просто разберется.
- Игнорировать семантику в Git проще. Если вы проигнорируете шаблон (например, * .pyc), он будет проигнорирован для подкаталогов все. (Но если вы действительно хотите игнорировать что-то только для одного каталога, вы можете). Кажется, что с SVN нет простого способа игнорировать шаблон во всех подкаталогах.
- Еще один пункт, связанный с игнорированием файлов. Git позволяет иметь "частные" настройки игнорирования (с использованием файла .git / info / exclude), которые никому не повлияют.
Объявление. 7. В современном git вы также можете настроить индивидуальное игнорирование для каждого пользователя, используя конфигурационную переменную core.excludesFile в ~ .gitignore (см. Man git-config).
По поводу № 5: Хотя обычно это правда, иногда Git все же делает лажать. По крайней мере, в Subversion проблемы, связанные с перемещением или удалением, почти всегда связаны с PEBKAC. Хотя приятно иметь автоматическое отслеживание перемещения / удаления, я бы по крайней мере оценил возможность явно указывать, что я делаю с файлами в репозитории, даже если мне это не нужно.
@Chris: Вы можете сделать это явно: git mv и git rm.
Я также хотел бы видеть вариант с единственным каталогом .svn для каждой рабочей копии, но для записи: Для №3: большинство инструментов (по умолчанию) игнорируют каталоги .svn. Для №6: вы можете устанавливать свойства рекурсивно.
3: "единственный .svn" каталог будет здесь с SVN 1.7, когда будет реализован WC-NG. 1: Чтобы получить чистку SVN, вы «экспортируете» поверх своего WC. 5: это не так просто, если вы переименуете файл, Git распознает его и сохранит историю, или обработает его как добавление и удаление в каталоге ?. 6/7: svn имеет глобальные настройки игнорирования для каждого пользователя.
Я столкнулся с проблемами №4, №6 и №7 с svn. +1 за указание на них w.r.t. мерзавец.
Я не понимаю, насколько правдивы №3 и №5 ... мне кажется, что смысл наличия .svn в каждой папке был бы в том, чтобы беспрепятственно перемещать вещи, а с одним центральным расположением гораздо труднее отслеживать движения ...
Я думаю, что №5 является прекрасным противовесом аргументу «git сложнее выучить, чем svn». Я видел, как так много новичков в системе управления версиями были сбиты с толку из-за этого. Они svn add файл, проделывают еще немного работы, решают удалить файл, а затем все взрывается им в лицо, когда они запускают svn ci.
Я, например, не очень беспокоюсь о распространении git. Но именно из-за этих мелочей, в частности №3 и №5, я перешел на git.
Самое смешное: Я размещаю проекты в Subversion Repos, но получаю к ним доступ через команду Git Clone.
Пожалуйста, прочтите Разработка с помощью Git в проекте Google Code
Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.
Использование Git в репозитории Svn дает мне преимущества:
- Могу работать распределен на нескольких машины, совершающие и вытягивающие из и им
- У меня есть репозиторий svn центральный
backup/public, чтобы другие могли его проверить - И они могут использовать Git самостоятельно.
это немного устарело, код Google работает постоянно, поэтому этот хак больше не нужен
@Sam, если вам не нравится git и / или не нравится mercurial.
Мне нравится Git, потому что он действительно помогает разработчикам в общении с разработчиками в средней и большой команде. Как распределенная система управления версиями, через систему push / pull, она помогает разработчикам создавать экосистему исходного кода, которая помогает управлять большим пулом разработчиков, работающих над одним проектом.
Например, вы доверяете 5 разработчикам и извлекаете коды только из их репозитория. У каждого из этих разработчиков есть своя собственная сеть доверия, из которой они извлекают коды. Таким образом, разработка основана на структуре доверия разработчиков, в которой ответственность за код разделяется между сообществом разработчиков.
Конечно, есть и другие преимущества, которые упоминаются в других ответах здесь.
«Почему Git лучше X» описывает различные плюсы и минусы Git по сравнению с другими SCM.
Вкратце:
- 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 [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
В чем Git действительно сияет, так это в разветвлении и работе с другими людьми.
Вы говорите, что GIT отслеживает контент, а не файлы. Я обнаружил, что SVN также делает это: я просто внес изменения в файл и сохранил его. SVN показал файл красным (измененным). Потом отменил в редакторе и снова сохранил. Затем SVN обновил статус до зеленого (не изменился), даже если файл был изменен (дата изменения более новая), но SVN распознала, что содержимое не было изменено по сравнению с оригиналом.
svn отслеживает изменения в файлах?
@awe, это называется отслеживанием файлов. попробуйте переименовать файл или переместить его в другое место вручную [тот же контент, новый файл (из-за нового пути / имени)]: узнает ли SVN, что это тот же файл, и сохранит ли предыдущие бесчисленные изменения, которые вы в него внесли? нет, наверное, нет.
TortoiseGit - code.google.com/p/tortoisegit| Разреженные проверки Git 1.7 - kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt
В нескольких ответах на это упоминалось, но я хочу четко указать 2 момента:
1) Возможность делать выборочные коммиты (например, git add --patch). Если ваш рабочий каталог содержит несколько изменений, которые не являются частью одного и того же логического изменения, Git упрощает выполнение фиксации, включающей только часть изменений. С Subversion это сложно.
2) Возможность совершить фиксацию без публикации изменений. В Subversion любая фиксация немедленно становится общедоступной и, следовательно, безотзывной. Это сильно ограничивает способность разработчика «фиксировать рано, фиксировать часто».
Git - это больше, чем просто VCS; это также инструмент для разработки патчей. Subversion - это просто VCS.
По поводу 1) Если вы используете TortoiseSVN, AnkhSVN и т. д., То очень легко (тривиально) выбрать, какие файлы с изменениями следует зафиксировать. Re 2) Если вы не хотите, чтобы другие разработчики получали ваш код, создайте ветку, а затем объедините ее, когда будете готовы, это несложно.
безвозвратно? Что ж, вы можете отменить слияние ошибочного коммита, и репозиторий останется таким, каким он был раньше. Но вы правы, это задокументировано. Но хорошо это или плохо? Я думаю, это зависит от обстоятельств ...
@schoetbi Нет, руководитель репозитория такой же, как и раньше. Сам репозиторий теперь содержит два коммита, тогда как было бы неплохо, если бы ни одного из них не было. Это лишний беспорядок, который замедляет вас, когда вы просматриваете журналы. Конечно, это может произойти и с git, особенно если некоторые разработчики имеют привычку нажимать сразу после фиксации. Но в git этого намного проще избежать.
Все ответы здесь ожидаемы, ориентированы на программистов, однако что произойдет, если ваша компания использует контроль версий вне исходного кода? Существует множество документов, не являющихся исходным кодом, для которых используется контроль версий, и они должны находиться рядом с кодом, а не в другой CMS. Большинство программистов не работают изолированно - мы работаем для компаний как часть команды.
Имея это в виду, сравните простоту использования как клиентских инструментов, так и обучения между Subversion и git. Я не вижу сценария, в котором распределенная система контроля версий любой будет проще в использовании или объяснении непрограммисту. Я бы хотел, чтобы меня доказали, что он ошибается, потому что тогда я смогу оценить git и действительно надеяться, что он будет принят людьми, которые не являются программистами, которым нужен контроль версий.
Даже тогда, если бы руководство спросило, почему мы должны переходить от централизованной к распределенной системе контроля версий, мне было бы трудно дать честный ответ, потому что он нам не нужен.
Отказ от ответственности: я рано заинтересовался Subversion (около v0.29), поэтому, очевидно, я предвзято, но компании, в которых я работал с того времени, получают пользу от моего энтузиазма, потому что я поощрял и поддерживал его использование. Я подозреваю, что именно так и происходит с большинством компаний-разработчиков программного обеспечения. Учитывая, что так много программистов подключаются к git, мне интересно, сколько компаний упустят преимущества использования контроля версий вне исходного кода? Даже если у вас есть отдельные системы для разных команд, вы упускаете некоторые преимущества, такие как (унифицированная) интеграция отслеживания проблем, при этом увеличивая требования к обслуживанию, оборудованию и обучению.
ИМХО, это единственная веская причина отдать предпочтение SVN. Короче говоря, проще объяснить непрограммисту, то есть тому, кто рассчитывал использовать его линейно и избегать сложных (= реальных) сценариев VC: конфликты, трехстороннее слияние, ветвления ... Я имею в виду, что вы бы в любом случае никогда не хочу позволять VCS объединять файл презентации PowerPoint.
«Большинство программистов не работают изолированно», похоже, предполагает, что бухгалтеры / маркетологи должны будут использовать то же хранилище, где хранится исходный код. Я не вижу в этом пользы; некоторые мои бывшие компании хотели стандартизировать такие вещи, но это неизбежно провалилось. Я думаю, что упрощенный подход может быть большим для менеджера, но чрезмерным упрощением для команд программистов, поэтому их объединение ведет к плохому компромиссу.
Что касается документов, которые идут вместе с программным обеспечением, вы правы - они должны быть версированы вместе. Я обнаружил, что это намного меньше, чем люди думают изначально (в итоге мы выбросили огромное дерево документов из репозитория с исходным кодом). Кроме того, вы можете многое сделать, чтобы упростить рабочие процессы технических писателей и т. д., Если это будет проблемой (а не должно).
@inger Я не думаю, что вы можете сказать «это единственная веская причина», поддержка инструментов AFAIK для Subversion намного превосходит Git, например TortoiseSVN и интеграция с Visual Studio и Java IDE, например Eclipse. Возможно, это не проблема для вас, но, безусловно, для нас. Я не упомянул об этом в своем ответе, потому что это отдельная проблема.
У непрограммистов в любом случае уже будут проблемы с подрывной деятельностью. Было бы гораздо лучше предоставить им реальное приложение для публикации документов с контролем версий, чем использовать svn-GUI. Почему бы не написать документы в вики с поправками. Есть даже несколько вики с поддержкой git, которые используют git в качестве хранилища данных. У программистов должен быть лучший инструмент для работы, и это git или Hg из-за свободы рабочего процесса.
@Keyo, да, это правда, что непрограммистам потребуется время, чтобы получить Subversion, но я думаю, им потребуется больше времени с git или Hg. Wiki хороши, если они поддерживаются, но, по моему опыту, разработчики с большей вероятностью будут поддерживать документы, связанные с исходным кодом, если они близки к этому исходному коду. Я согласен с inger в том, что документов, подпадающих под эту категорию, не так много, но они, безусловно, существуют. Интересно, что вы говорите, что git / Hg - лучший инструмент для работы, это общее заявление, которое, вероятно, не верно для всех обстоятельств, имеет ли git и Hg такую же хорошую интеграцию, как SVN?
Например, я имею в виду интеграцию в Windows (TortoiseSVN) и Visual Studio (AnkhSVN). Всем ли разработчикам нравится использовать командную строку вместо красивого графического интерфейса или IDE? Я говорю о том, что не думаю, что вы можете категорически утверждать, что git / Hg - лучший инструмент для работы, потому что, если людям не нравится клиент VCS, они не будут использовать этот инструмент, нет независимо от того, сколько свободы это дает вашему рабочему процессу.
Subversion очень проста в использовании. За последние годы я ни разу не обнаружил проблемы или того, что что-то работает не так, как ожидалось. Также есть много отличных инструментов с графическим интерфейсом и большая поддержка интеграции SVN.
С Git вы получаете более гибкую систему контроля версий. Вы можете использовать его так же, как SVN, с удаленным репозиторием, в котором вы фиксируете все изменения. Но вы также можете использовать его в основном в автономном режиме и только время от времени отправлять изменения в удаленный репозиторий. Но Git более сложен и требует более крутого обучения. Я впервые обнаружил, что совершаю переход к неправильным ветвям, косвенно создаю ветки или получаю сообщения об ошибках с небольшим количеством информации об ошибке и о том, где я должен искать с помощью Google, чтобы получить лучшую информацию. Некоторые простые вещи, такие как замена маркеров ($ Id $), не работают, но GIT имеет очень гибкий механизм фильтрации и перехвата для объединения собственных скриптов, поэтому вы получаете все, что вам нужно, и многое другое, но для этого требуется больше времени и чтения документации. ;)
Если вы работаете в основном в автономном режиме с локальным репозиторием, у вас нет резервной копии, если что-то потеряно на вашем локальном компьютере. С SVN вы в основном работаете с удаленным репозиторием, который одновременно является вашей резервной копией на другом сервере ... Git может работать таким же образом, но Линус не ставил перед собой цель создать что-то вроде SVN2. Он был разработан для разработчиков ядра Linux и нужд распределенной системы контроля версий.
Git лучше SVN? Разработчики, которым нужна лишь некоторая история версий и механизм резервного копирования, могут легко и легко работать с SVN. Разработчики, часто работающие с ветками, тестирующие больше версий одновременно или работающие в основном в автономном режиме, могут извлечь выгоду из функций Git. Есть несколько очень полезных функций, таких как хранение, которых нет в SVN, которые могут облегчить жизнь. Но, с другой стороны, не всем нужны все функции. Так что я не могу видеть мертвых SVN.
Git нужна лучшая документация, и отчеты об ошибках должны быть более полезными. Кроме того, существующие полезные графические интерфейсы встречаются редко. На этот раз я нашел только 1 графический интерфейс для Linux с поддержкой большинства функций Git (git-cola). Интеграция с Eclipse работает, но она не выпущена официально, и официального сайта обновлений нет (только некоторые внешние сайты обновлений с периодическими сборками из магистрали http://www.jgit.org/updates) Поэтому в наши дни наиболее предпочтительным способом использования Git является командная строка.
Эрик Синк из SourceGear написал серию статей о различиях между распределенными и нераспределенными системами контроля версий. Он сравнивает плюсы и минусы самых популярных систем контроля версий. Очень интересное чтение.
Статьи можно найти в его блоге, www.ericsink.com:
Во-первых, одновременное управление версиями кажется простой проблемой. Это совсем не так. Так или иначе...
SVN довольно не интуитивно понятен. Git еще хуже. [sarcastic-speculation] Это может быть связано с тем, что разработчики, которым нравятся сложные проблемы, такие как параллельный контроль версий, не очень заинтересованы в создании хорошего пользовательского интерфейса. [/ 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 бушует уже некоторое время, и каждый имеет собственное мнение о том, что лучше. Об этом даже говорили в ходе нашего вебинара по Subversion в 2010 году и позже.
Хайрам Райт, наш директор по открытому исходному коду и президент Subversion Corporation, рассказывает о различиях между Subversion и Git, а также о других распределенных системах контроля версий (DVCS).
Он также говорит о грядущих изменениях в Subversion, таких как Working Copy Next Generation (WC-NG), которые, по его мнению, заставят ряд пользователей Git вернуться к Subversion.
Посмотрите его видео и дайте нам знать, что вы думаете, комментируя этот блог или размещая сообщения на наших форумах. Регистрация проста и займет всего несколько минут!
Очевидно предвзято, так как его инструмент основан на Subversion. Просто говорю.
Мне очень нравится возможность управлять локальными ветвями моего исходного кода в Git, не запутывая центральный репозиторий. Во многих случаях я проверяю код с сервера Subversion и запускаю локальный репозиторий Git, чтобы иметь возможность сделать это. Также замечательно, что инициализация репозитория Git не загрязняет файловую систему множеством надоедливых папок .svn повсюду.
Что касается поддержки инструментов Windows, TortoiseGit очень хорошо обрабатывает основы, но я по-прежнему предпочитаю командную строку, если я не хочу просматривать журнал. Мне очень нравится, как Tortoise {Git | SVN} помогает при чтении журналов фиксации.
В последнее время я живу в мире Git, и мне он нравится для личных проектов, но я не смог бы пока переключить на него рабочие проекты из Subversion, учитывая изменение мышления, которое требуется от персонала, без каких-либо неотложных преимуществ. Более того, самый крупный проект, который мы выполняем внутри компании, чрезвычайно зависит от svn: externals, который, насколько я видел до сих пор, не работает так хорошо и плавно в Git.
Я думаю, что с Subversion все в порядке ... пока вы не начнете объединяться ... или делать что-то сложное ... или делать что-то, что Subversion считает сложным (например, делать запросы, чтобы узнать, какие ветки испортили конкретный файл, откуда происходит изменение фактически, обнаружение копирования и вставки , так далее)...
Я не согласен с победившим ответом, говоря, что главное преимущество GIT работает в автономном режиме - это, безусловно, полезно, но это больше похоже на дополнительный вариант для моего варианта использования. SVK также может работать в автономном режиме, но для меня нет никаких сомнений в том, в какой из них потратить свое время на обучение).
Просто он невероятно мощный и быстрый и, после того, как вы привыкли к концепциям, очень полезен (да, в этом смысле: удобен для пользователя).
Дополнительные сведения об истории слияния см. Здесь: Используете git-svn (или аналогичный) * просто *, чтобы помочь с слиянием svn?
Дэвид Ричардс Блог WANdisco по Subversion / GIT
The emergence of GIT has brought with it a breed of DVCS fundamentalists – the ‘Gitterons’ – that think anything other than GIT is crap. The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don’t employ senior software engineers exclusively. That’s ok but it’s not how the rest of the market thinks, and I am happy to prove it: GIT, at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market.
The problem we saw was that the Gitterons were firing (cheap) shots at Subversion. Tweets like “Subversion is so [slow/crappy/restrictive/doesn't smell good/looks at me in a funny way] and now I have GIT and [everything works in my life/my wife got pregnant/I got a girlfriend after 30 years of trying/I won six times running on the blackjack table]. You get the picture.
Обратите внимание, что Дэвид Ричардс мог быть непредвзятым: продукт, который он создает, основан на Subversion (или на идеях Subversion), поэтому, конечно, он будет сторонником Subversion и противником Git.
По иронии судьбы, Git был создан специально потому, что разработка программного обеспечения не происходит на островах. Это дебильная цитата.
Хотя я использую git, я также был бы счастлив работать с любыми приличными DVCS, например, с Mercurial. Требуется время, чтобы концепция DVCS приобрела популярность, и теперь я вижу, что огромное количество проектов с открытым исходным кодом перешло на git.
Изображая критиков svn фундаменталистами, Дэвид обходит в сторону фундаментальную проблему: архитектура подрывной деятельности - это тупик. Дело не в том, что git является конечной точкой VCS, у него, безусловно, есть свои недостатки, но git, mercurial, darcs и многие другие VCS имеют принципиально более элегантные модели репозиториев. Subversion никогда не выполнит слияние, потому что модель ветки directory == делает невозможным реальный прогресс. Такие компании, как David's, могут накапливать все больше и больше помады на свинье, но svn неизбежно будет все больше и больше отставать от современных достижений.
Почему я считаю, что Subversion лучше Git (по крайней мере, для проектов, над которыми я работаю), в основном благодаря удобству использования и более простому рабочему процессу:
http://www.databasesandlife.com/why-subversion-is-better-than-git/
Для людей, которым нужен хороший графический интерфейс Git, Syntevo SmartGit может быть хорошим решением. Его проприетарный, но бесплатный для некоммерческого использования, работает на Windows / Mac / Linux и даже поддерживает SVN с использованием какого-то моста git-svn, я думаю.
Это неправильный вопрос. Слишком легко сосредоточиться на проблемах git и сформулировать аргумент о том, почему Subversion якобы лучше, по крайней мере, для некоторых случаев использования. Тот факт, что git был изначально разработан как низкоуровневый конструктор для управления версиями и имеет барочный интерфейс, ориентированный на разработчиков Linux, облегчает священным войнам получение поддержки и воспринимаемую легитимность. Сторонники Git бьют по барабану миллионами преимуществ рабочего процесса, которые парни из svn объявляют ненужными. Довольно скоро вся дискуссия оформляется как централизованное против распределенного, что служит интересам сообщества корпоративных инструментов svn. Эти компании, которые обычно публикуют наиболее убедительные статьи о превосходстве подрывной деятельности на предприятии, зависят от предполагаемой небезопасности git и готовности svn к предприятию для долгосрочного успеха своих продуктов.
Но вот проблема: Subversion - архитектурный тупик.
Принимая во внимание, что вы можете взять git и довольно легко создать централизованную замену Subversion, несмотря на то, что svn существует более чем в два раза дольше, никогда не удавалось заставить даже базовое отслеживание слияния работать где-либо так хорошо, как в git. Одна из основных причин этого - дизайнерское решение сделать ветки такими же, как каталоги. Я не знаю, почему они пошли по этому пути изначально, это, безусловно, очень упрощает частичное оформление заказа. К сожалению, это также делает невозможным правильное отслеживание истории. Теперь очевидно, что вы должны использовать соглашения о компоновке репозитория Subversion для отделения ветвей от обычных каталогов, а svn использует некоторые эвристики, чтобы заставить вещи работать для повседневных случаев использования. Но все это лишь прикрытие очень плохого и ограничивающего проектного решения на низком уровне. Возможность выполнять сравнение по репозиторию (а не по каталогу) является базовой и важной функцией для системы управления версиями и значительно упрощает внутреннее устройство, позволяя создавать более умные и полезные функции поверх нее. Вы можете увидеть, сколько усилий было приложено для расширения подрывной деятельности, и, тем не менее, насколько она отстает от нынешнего поколения современных VCS с точки зрения фундаментальных операций, таких как разрешение слияния.
А теперь вот мой искренний и агностический совет всем, кто все еще считает, что Subversion достаточно хороша для обозримого будущего:
Subversion никогда не догонит новые разновидности VCS, которые извлекли уроки из ошибок RCS и CVS; это техническая невозможность, если они не переоборудовали модель репозитория с нуля, но тогда это действительно было бы svn, не так ли? Независимо от того, насколько вы думаете, что не обладаете возможностями современной VCS, ваше незнание не защитит вас от ловушек Subversion, многие из которых являются ситуациями, которые невозможно или легко разрешить в других системах.
Крайне редко техническая неполноценность решения настолько очевидна, как с svn, я бы никогда не высказал такого мнения о win-vs-linux или emacs-vs-vi, но в данном случае это так clearcut, а контроль версий - настолько фундаментальный инструмент в арсенале разработчика, что я считаю, что об этом следует говорить однозначно. Независимо от требования использовать svn по организационным причинам, я умоляю всех пользователей svn не позволять своему логическому уму формировать ложное убеждение, что более современные системы контроля версий полезны только для крупных проектов с открытым исходным кодом. Независимо от характера вашей разработки, если вы программист, вы станете более эффективным программистом, если научитесь использовать лучше спроектированные системы контроля версий, будь то Git, Mercurial, Darcs или многие другие.
За разговором Линуса интересно смотреть. Он жестоко взламывает централизованные системы контроля версий, такие как Subversion и CVS. Однако выступление Рэндала Шварца youtube.com/watch?v=8dhZ9BXQgc4 более конструктивно, информативно и убедительно.