В настоящее время я глубоко в Git, прежде чем освоить SVN. Его первый серьезный опыт управления системой управления исходным кодом.
Интересно о возможности-стоимости не обучения (или даже де-изучения того, что мало я узнал о) SVN. Есть ли что-то, что мне нужно следить?
Есть ли вещи, которые просто не выполняются или непомерно трудны в Git по сравнению с SVN?
Git не может svn lock документы, чтобы кто-то мог запретить другим редактировать объект, не связанный с автоманией (например, Word или Excel).
Git не может проверить поддерево и использовать его, как если бы это был полный репозиторий.
Например, с Subversion вы можете проверить каталог "trunk" и использовать его так, как если бы это был репозиторий. Вы также можете проверить "branch/feature1" и использовать это. С помощью Git можно только проверить корневой каталог (хотя с недавними версиями вы можете сделать разреженную проверку, которая не загружает все файлы, вам все равно нужно проверить корень). В Git вы должны использовать ветки вместо проверки поддеревьев.
Я думаю, что одним из немногих вариантов использования, в которых вы можете использовать Subversion вместо git, является то, что вы пытаетесь управлять очень большим хранилищем двоичных файлов, где люди в основном хотят только самую последнюю версию. например скажем, вы разрабатываете игру, и художники должны отслеживать изменения всех произведений искусства, но вся история репозитория будет огромной (100 гигабайт).
Чтобы быть справедливым по отношению к git, это прецедент, который очень далек от того, что он был предназначен для создания (управления репозиториями исходного кода), и существуют различные обходные пути или расширения, которые могут помочь, если вы действительно хотите использовать git для этого, например:
... но он все еще является областью, где, вероятно, будет предпочтительнее SVN. Там пара краткая презентация на эту тему от GitTogether пару лет назад.
Git не может хранить пустые каталоги. Возможно, это преимущество, но одно дело, что git не может делать, но svn может.
Эта Wiki имеет хорошее сравнение: https://git.wiki.kernel.org/index.php/GitSvnComparison
Обобщенная
Я бы сказал, что вы можете делать почти все, что имеет значение в git и даже больше, чем подрывная деятельность. Это не должно волноваться. Однако оба они популярны и заслуживают вашего внимания, особенно если вы используете программирование с открытым исходным кодом.
Я бы, однако, подумал о том, что git будет труднее изучить, но как только вы его повесили, люди обычно увлекаются и находят других НКМ ниже. Распределенная поддержка для git превосходна (есть и другие, но git, вероятно, самый распространенный), что бывает полезно для множества других задач, кроме как управлять исходным кодом. git можно считать ZIP-утилитой на стероидах и может быть быстро развернута для отслеживания изменений в общей файловой системе и для эффективного репликации изменений между хостами.
В окнах есть некоторые проблемы с git:
Но я бы рассмотрел вещи, которые есть git, а SVN - нет. Отсутствие явной поддержки веток в SVN является серьезной проблемой - реализация git очень приятная и позволяет вам веткиться, даже не думая о ветвях. Возможность работать в автономном режиме также является основным лечением.
Для нас самая важная особенность SVN заключается в возможности создания файлов блокировки репозиториев. Поскольку мы работаем с бинарными и неуправляемыми САПР файлами, рабочий процесс любого DVCS не работает здесь.
Вы не можете ограничить доступ для чтения к части репо (т.е. разрешить чтение определенных файлов или только часть истории). Это прямое следствие того факта, что вы можете клонировать полный репозиторий (как объяснялось в ответах Тео и Марк Лонгэй). Если вам нужны разные уровни доступа для чтения для разных файлов, вы должны поместить их в разные репозитории (которые могут быть включены в качестве подмодулей в основное репо).
Обратите внимание, что вы можете ограничить доступ на запись к репо на основе многих критериев (путь, имя файла, модификация истории). Для этого вам нужно использовать специальное программное обеспечение в дополнение к git (например, gitosis), но это похоже на Subversion.
На практике выше, как правило, не проблема, потому что в git идея состоит в том, что репозиторий содержит файлы, которые обычно используются вместе (например, исходный код одной программы или проекта) - поэтому обычно ограничение доступа для чтения к часть бессмысленна, потому что вам нужны все файлы для создания/работы с проектом. Однако, если вы ставите много несовместимых вещей в один репозиторий git, это может вас укусить.
Subversion - это центральный репозиторий
В то время как многие люди захотят иметь распределенные хранилища для очевидных преимуществ скорости и нескольких копий, бывают ситуации, когда центральный репозиторий более желателен. Например, если у вас есть критический фрагмент кода, который вы не хотите, чтобы кто-либо мог получить доступ, вы, вероятно, не захотите поставить его под Git. Многие корпорации хотят сохранить свой код централизованным, и (я думаю) все (серьезные) правительственные проекты находятся в центральных хранилищах.
Subversion - это обычная мудрость
Это означает, что многие люди (особенно менеджеры и боссы) имеют обычный способ подсчета версий и видят развитие как "одну линию", время от времени жестко закодированную в их мозг. Не обижайтесь, но Git либеральность непросто глотать. В первой главе любой книги Git говорится о том, чтобы выпустить все обычные идеалы из своего разума и начать заново.
Subversion делает это в одну сторону, и ничего больше
SVN - это система управления версиями. У него есть один способ сделать свою работу, и каждый делает то же самое. Период. Это облегчает переход к/из SVN от/к другому централизованному VCS. Git НЕ является даже чистым VCS - это файловая система, имеет множество топологий для настройки репозиториев в разных ситуациях - и нет никакого стандарта. Это затрудняет выбор.
Другие преимущества:
SVN supports empty directories
SVN has better Windows support
SVN can check out/clone a sub-tree
SVN supports exclusive access control svn lock which is useful for hard-to-merge files
SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.
Нашел это и согласен с ним. Опять новые птицы довольно агрессивные, когда вы касаетесь Git. Я не могу доверять Git или github до тех пор, пока не появятся еще несколько изменений безопасности, вроде перехода на один шаг за пределы hackable ssh-ключей.
При распределенном характере Git нет единого места (сервера), где вы /sysadmin можете создать резервную копию всей базы кода. Каждый node должен самостоятельно создавать резервные копии или объединять их с node, который берет ежедневные резервные копии.
Еще две вещи, которые может выполнить svn, и я пропускаю в git: