После двух с половиной лет разработки свет увидел новый major релиз централизованной системы управления версиями subversion:,. Скачать для Windows (GUI,CMD) или (только CMD). Скачать. Для.NIX можем собрать из сами. Нумерованные ошибки и предупреждения Теперь в случае ошибки нет необходимости гуглить ее сложносоставной текст — достаточно номера — как у компиляторов или wix.

Только одна папка.svn в корне Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку '.svn' — теперь эта папка создается только в корне рабочей копии. Ускорение работы по HTTP За счет отказа от полной совместимости с редко используемым WebDAV и использовании упрощенного протокола, называемого авторами HTTPv2. Новая утилита svnrdump Позволяет сделать dump удаленного репозитория не имея к нему админского доступа.

Новая команда svn patch Позволят применить к рабочей копии патч в формате unidiff. Метки:. Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, андронный коллайдер, задача трех тел. Например эту «фичу» они умели изначально:) Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку '.svn' теперь эта папка создается только в корне рабочей копии.

К тому же там намного более удобно делать Merge. Но самое главное отличии от SBN — они децентрализованные. Это значит что ты (и все твои напарники) могут продолжать совершенно спокойно работать даже если сам сервер с репозиторием (или коннект к нему) лежит. Совсем не всегда хорошей идеей является хранение исходников продукта в стране где власть может плевать на законы:) + команда разработчиков частенько бывает разделена океанами. Git/Hg уменьшают количество шагов, которые нужно сделать.

Позволяет сделать dump удаленного репозитория не имея к нему админского доступа. Новая команда svn patch. Позволят применить к рабочей копии патч в формате unidiff. Добавить метки. Пометьте публикацию своими метками.

Понятно, что в SVN можно сделать всё, что умеют Git/Hg: настроить локальное зеркало удаленного репозитория, делать и мерджить бранчи, но в Git/Hg это просто удобнее. Можно работать над какой-то фичей, а если срочно что-то нужно поправить в текущей версии, но фича ещё не готова, просто делаешь update к соответствующему changeset, исправляешь, комитишь, делаешь update к своей работе, продолжаешь работать, и это всё делается очень быстро и просто. «Центральный» реп можно поднять вместе с коммитами и ветками из любой локальной копии. Но возьмем, к примеру, случай, когда разработчик работает над некой фичей. Он работает в отдельной ветке, текущее состояние «центрального» репа ему ни к чему — у него своя задача. Предположим, падает этот самый «центральный» реп.

Как дальше работать пользователю svn? Да никак — ждать, пока поднимут сервер, или копить коммит в пару мегабайт текста. Как дальше работать пользователю git? Как и раньше работал — о падении «центрального» репозитория он узнает только после того как доделает фичу, сольет ветку с ней в главную и попытается залить ее на упавший реп. И даже если до этого момента реп не починят, он пожмет плечами, создаст новую ветку и начнет работать над новой фичей. Предположим, что пользователя snv вполне устраивает ситуация с коммитом в несколько мегабайт.

Он продолжает дальше работать, не делая коммитов, и тут обнаруживает ошибку в главной ветке (которая влияет не только на его фичу, но и на все прочее). Ему нужно переключиться в центральную ветку, сделать фикс, переключиться обратно. А он не может этого сделать, т.к. Репозиторий лежит. Что в этом случае сделает пользователь git? Переключится на главную ветку (она у него есть локально), сделает фикс, попытается пушнуть все это в центральный реп, скажет: «Ой, центральный реп лежит», переключится в свою рабочую ветку, смержит главную, и продолжит работать.

А фиксы зальет на сервер тогда, когда его поднимут. И какая польза проекту от такого коммита в метро?

Кто им может воспользоваться? Покрашился реп? Ну, обычные регулярные бекапы (даже бекап на коммит) никто не отменял, с таким успехом — какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?

Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать: svn copy CURRENTURLOFWORKINGCOPY SOMEBRANCH svn switch SOMEBRANCH svn commit -m «work in progress» svn switch WHATEVERIWASWORKINGONBEFORE А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль. Опять же, если есть необходимость править несколько веток одновременно, которые нужны только мне самому и локально хм, зачем тут система контроля версий для коллективной разработки? И какая польза проекту от такого коммита в метро?

Кто им может воспользоваться? Я выйду из метро, дойду до интернета и запушу все в центральный реп. При этом у меня с собой в метро будут все ветки, и я смогу нормально коммитить, а не набирать гигантских размеров коммит. какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария? Все разработчики в сумме держат полную и атуальную версию репа. Восстанавливаем «центральный» реп из локального от любого автора, отсальные делают в него пуш — вуаля, полностью актуальный реп со всеми коммитами. Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать: Я говорил не об этом.

Предположим, вы делаете некоторую фичу и обнаруживаете баг в главной ветке. Вам нужно переключиться в главную ветку и поправить этот баг. Но у вас есть незакоммиченные изменения, которые коммитить сейчас нельзя, т.к. Код банально не дописан и не проверен. В git вы делаете stash, переключаете ветку, делаете фикс, переключаетесь обратно, делаете stash apply.

Как вы разрулите это в svn. А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль. Этот коммит зальется в центральный реп, как только оный станет доступен.

И это могут быть несколько красивых коммитов, а не один толстый с тучей правок. Я вижу, что вы не совсем понимаете или совсем не понимаете смысл работы в ветках. Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления. И как потом эти внесенные изменения потом перенести в вашу рабочую копию? Вы совершенно не поняли, о чем я.

И непонимание это кроется именно в особенностях работы с svn. Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.

В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию. Да и вообще создание второй рабочей копии выглядит как извращение, откровенно говоря, в любом случае. И как потом эти внесенные изменения потом перенести в вашу рабочую копию? Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.

Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки. В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально. В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию. Нет, не извращение — особенность.

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

Ошибка мешает вашей дальнейшей разработке. Ее нужно поправить. Но править в вашей рабочей ветке нельзя, т.е.

Этот фикс не попадет в мастер-ветку до окончания разработки фичи, а значит не попадет и к остальным разработчикам и в релиз (если он состоится до завершения разработки фичи). Я говорю с вами и натыкаюсь на стену непонимания. Вы, судя по всему, совершенно не понимаете принципов работы в ветках или принципов работы git`а. На самом деле да, возможность работы без центрального сервера лично для меня далеко не самая главная причина перехода с svn. Основные причины: 1) Лучшая защита от дурака.

C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить. 2) Более удобная работа с ветками. Про это уже сказали 3) git stash. Тоже упоминался 4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд 5) github 6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер 7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка.git (рад что в.svn теперь также).

В Git/Mercurial каждая рабочая копия и есть полноценный репозитарий. Потому два разработчика могут спокойно обмениваться коммитами без какого-либо центрального сервера. Что касается ответа на вопрос: А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит свои фичи что-то тут не. Вы представляете как устроен процесс разработки, например, ядра Linux? Упрощённо это происходит так.

Есть много разработчиков, которые пишут код, фиксят баги. Потом полученные коммиты присылаются людям, отвественным за определённые области в ядре. После review, тестов и прочего ответственные включают или не включают конкретные коммиты в свои основные бранчи.

И уже после этого Торвалдс выбирает нужные коммиты из репозиториев этих ответственных за подсистемы и включает в свою основную ветвь. В определённый момент принимается решение и выпускается новая версия ядра. В итоге что имеем: нет никакого центрального репозитория, копошится куча народу, каждый в своей песочнице. Но тем не менее. Релиз ядра — это просто состояние основной ветки в репозитории Линуса Торвалдса в определённый момент времени.

Так что и с любым другим проектом — просто конкретный репозиторий (например, репозиторий тимлида) мы объявляем центральным и из него берём код для релизов. На самом деле часто центральными репами являются bare repos, но сути это не меняет. 1) У вас есть не только локальная история (ваши изменения) но и полная история всех изменений до времени последнего pullа. Чтобы посмотреть историю, вам не надо обращаться к центральному серверу, вся история есть уже у вас на машине. Просмотр истории в git/hg банально быстрее.

1-2-3) Выясняется, что не только синхронизация нужна Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним. Разные механизмы работы. При централизованных системах все исходники всегда на центральном сервере. При этом ни один программист не может надолго «уйти в подвал» или работать с каким-то своим локальным репозиторием. Все стараются почаще комититься апдейтиться.

В результате: -в одном месте видно кто и что сделал -в любой момент можно уволить кого-угодно — много кода не пропадёт.можно легко пережить «смерть» любого рабочего компьютера (а в больших коммандах это бывает часто) -удобно принимать административные решения типа «на эту ветку мы забьём, а эти две сольём» -легко кому-то запретить доступ куда-то Центральный сервер Гита решает проблему только частично. Им можно пользоваться, а можно и забить, даже если он есть:) — тут уж чисто административные меры можно принимать для борьбы с этим. Все это какие-то не менее странные подробности.

Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. Это всего лишь кусочек выполнения таска, который в таком виде никому не нужен. Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один? Таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины. При наличии центрального репо ветки так же поддаются контролю. Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.

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

Может быть Вы и правы, а я чего-то не понимаю. Но вот Вы знаете много крупных (от нескольких десятков человек и выше) IT-фирм, использующих штатно git mercurial, а не что-то централизованное? Вот в радиусе моей видимости соотношение где-то 10:1 в пользу svn tfs. Не знаю, может случайность такая. Но мне кажется, что в большой фирме степень бардака и так большая а еще и увеличивать её исходниками, разбросанными по разным компьютерам — себе дороже. Я знаю фирмы, где используется не Svn, где Svn комбинируется с другими системами (Git или Mercurial).

Но оглянитесь: некоторые фирмы до сих пор используют CC, VSS и CVS. Крупные IT-фирмы на то и крупные, чтобы плестись в хвосте эволюции — у них стоимость внедрения новых решений куда выше, чем у средних и мелких — а ресурсы точно так же выжимаются по максимуму, и найти силы на общий переход, да еще и со спорными преимуществами, бывает просто невозможно.

Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения. Есть «центральный» репозиторий, в котором хранятся результаты работы всех авторов. Есть локальные репозитории у каждого из авторов, которые отличаются от центрального только наличием изменений и веток, необходимых в данный момент только этому автору (например, фича, над которой работает только он). В случае необходимости это все сливается в «центральный» реп. Где тут размазанность? Более того — при падении «центрального» репозитория его можно будет восстановить вместе с коммитами и ветками из локальной копии любого автора.

А авторы смогут спокойно работать даже при упавшей сети или умершем «централном» репозитории, не делая вообще никаких дополнительных действий. «Центральный» я пишу в кавычках, потому что у git такого понятия нет. Есть удаленные репозитории, коих к локальному можно подключить хоть сто. Ну, менеджера, который не в состоянии понять содержание коммита в любом случае стоит гнать, независимо от используемой системы управления версиями. Речь о том, что в централизованной системе у менеджера хотя бы есть возможность эти коммиты видеть в реал-тайме.

Вот бывает ставит заказчик задачу: ускорить быстродействие на 400%. При децентрализованной системе работы эта задача уйдет программеру и он её не пушнет на центральный сервак, пока не выполнит полностью (пусть это займет 4 дня).

В централизованной — за 4 дня может быть сделано 20 коммитов с комментами типа «добавлено кеширование +20%», «оптимизированы запросы к базе +60%». В итоге если заказчик на второй день спросит как дела, менеджер с централизованной системой скажет — уже стало на 80% лучше, можете взять текущий билд проверить, а мы продолжаем работать. Менеджер децентрализованной может ответить только «хз, ща пойду спрошу, показать пока нечего».

Извините, но я все равно Вас не понимаю. Вы говорите, что централизация заставит сотрудников заливать код раз в день и чаще на центральный сервер? Нет, не заставит. Всегда найдутся люди, которые копят ченжи и выкладывают по завершении таска — это вопрос баланса между комфортом программиста и требованиями решаемой задачи. Если Вам нужны итеративные улучшения, если есть возможность этот итеративный прогресс подтверждать тестами, то просто попросите человека выкладывать почаще — и не важно, какая при этом у вас используется система, это не вопрос техпроцесса совершенно. Вам уже говорили, есть ssh-ключи, есть различные методы авторизации. Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой.

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

Все всё пробовали. Только всегда всё в конечном итоге сводится к тому, что всё равно есть некий центральный репозиторий, куда все пушат свои изменения. Поэтому децентрализованность выливается по сути только в то, что есть возможность локально коммитить и откатываться, если что-то поломал. Про прочие удовольствия (сейчас я говорю только про гит) вообще молчу. Гитовские сабмодули — тихий ужас по сравнению с svn externals.

Все превозносимые фичи по работе с ветками (типа «как что-то понадобилось, сделал git branch и правишь изменения уже в новой ветке!») разом пропадают, если у нас есть build-каталог внутри дерева. Потому что при сборке пакета, если не писать полностью самому правила сборки (что есть неправильно), debhelper сам решает, в каком именно каталоге собирать. И поскольку структура файловой системы заранее неизвестна, сборка ВСЕГДА идёт не ниже корня пакета. Так что единственным способом является создавать для всего структуру типа: /workspace/ — каталог с проектами /workspace/projectname/ — «проект» /workspace/projectname/projectname-scm/ — настоящая папка с исходниками из гита Это не так удобно, и опять-таки, не позволит хранить каталог debian/ с инструкциями для сборки в SCM, только в /workspace/projectname/. Это не есть удобно. А можно подробнее про тихий ужас? Прописываем субрепу без ревизии.

При каждом обновлении основной репы получаем обновления и субреп. Внезапно и не вовремя. Прописываем субрепу с ревизией. Чтобы обновить субрепы нужно узнать номер последней ревизии, изменить проперти основной репы и обновиться. Много телодвижений. Гит: основная репа и субрепы обновляются независимо.

Простыми движениями мы можем в любой момент: 1. Обновить вообще всё 2.

Обновить только основную репу 3. Обновить субрепы 4. Обновить конкретные субрепы. Чтобы обновить без сабреп, достаточно использовать svn up -ignore-externals. Чтобы обновить экстернал, заходим в каталог с экстерналом, делаем svn up, заодно узнаём новую ревизию, много телодвижений. Я просто запишу это «простое» телодвижение: alias.up = '!git pull origin master;git submodule foreach -recursive 'git pull origin master' Когда я работаю с корпоративным проектом, который использует пачку внутренних библиотек, я не хочу отслеживать состояние сторонних библиотек и самолично их апдейтить.

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

Одной командой это, разумеется, сделать нельзя. Плюс интересное возникает при попытке сделать сабмодуль частью репозитория. Казалось бы, в чём проблема вмержить просто всю историю сабмодуля в родительскую, подправив пути. Но нет, при мерже репозиториев кутима мы попробовали ВСЕ способы, которые нашли в интернете, и в лучшем случае получали потерю половины истории.

Свежий чекаут вообще всегда притягивает последнюю версию. И в свне, и в гите, и даже во всяких дарксах. Почему бы сабмодулям без указания ревизии надо вести себя по-другому? Если это так сложно, воспользуйтесь гуёвыми утилитами. И, да, их в свн, точно так же, как и в гите, можно просто отредактировать в файлике.

Только svn, в отличие от гита и его.gitmodules/.gitignore, складывает свою информацию в.svn/, а не срёт ей в корне репозитория. Последние баги в транк попадать не должны.

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

Бинарной ну я даже не знаю, такое только в опенсорсе бывает, и то у школьников. Повторюсь, хотите жесткой привязки к конкретной ревизии — в свне эта возможность есть. А в гите обратной возможности нет. Потому что гит хранит не только ссылку на субрепу, но и сами исходники из неё. Именно поэтому после коммита в субрепу надо сделать коммит в суперрепу, чтобы изменения отразились и на ней. Что за гуёвые утилиты?

В гите мне не приходится ничего дополнительно редактировать после каждого апдейта субмодулей. И вопрос не в том какая система контроля версий лучше, а какой подход лучше. Разумеется специальными скриптиками можно сделать работу с свн как в гите и с гитом как в свн-е. В данном случае подход свн-а вида «либо полная недетерминированность версии, либо кропотливое ручное изменение версий» никуда не годится по сравнению с гитовским «обновляемся по требованию» ога, сферический транк в вакууме всегда стабилен х) а с чего ты взял, что неожиданно? Вполне ожидаемо.

Библиотека развивается и поддерживать 100500 интерфейсов никому не нужно. Гит не хранит исходники из сабрепы, даже каталог под неё (да, это тоже замечательная особенность гита — нельзя сохранить структуру каталогов). После чекаута надо делать git submodule update -init. Впрочем, не понимаю, какое отношение это имеет к вопросу. Git clone, bzr branch, darcs get, svn co — все они всегда выкачивают последнюю версию репозитория.

Спрашивается, почему поведение сабмодуля, не привязанного к ревизии, должно при чекауте должно быть иным? Тот же TortoiseSVN или просто любимые IDE.

К счастью, в отличие от гита, который имеет исключительно набор бинарников (что вынуждает все веб-обёртки и аналогичные утилиты делать system(.) и парсить вывод), в свне есть библиотеки и можно работу с правкой любых свойств сделать сколь угодно удобной и кропотливо что-то править нигде не нужно. Если же говорить о подходе, то подход «обновляем по требованию» не лучше подхода «либо последняя версия, либо обновляем по требованию».

В школьной лаборатной или студии из полутора человек, возможно, библиотеки и «развиваются» подобным образом. В более-менее серьёзном софте — нет.

Qt несколько лет поддерживала классы от Qt3, майкрософт десяток лет минимум поддерживал ansi-версии функций от winapi (если не поддерживает до сих пор). И так в общем-то делают все нормальные люди.

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

Тот же меркуриал тоже не любит, когда ему не подсказывают, что переименовали или скопировали. Только Гит умеет автоматом детектировать такие операции, но и он делает это не идеально, если содержимое файла при переименовании изменилось. Это НЕлогичное поведение. Осталась папка с таким же именем, изменилось только содержание. Пример из жизни: решил поменять какую-то либу (уже в упор не помню какую) на новую. Снес из проекта старую папку с ней, вставил новую.

Получил конфликт, на разгребание которого потратил время. Гит, к примеру, это съест и не поперхнется.

Второй пример: переделывали структуру папок с иконками для сайта. В итоге одна из папок после перетасовки оказалась на своем же месте. Точнее, на ее месте оказалась новая папка с таким же именем и содержанием. Но svn восприняла ее как новую и выкатила конфликт. И опять потеря времени на разруливание глупейшего конфликта. Вы ошибаетесь, переход может быть очень болезненным. Например, если в репозитории хранятся большие файлы (1ГБ), на 32ух-битных машинах меркуриал банально будет падать по out of memory.

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

Меркуриал и Гит — не замена Свн-а. Это другие системы, и подходы к работе с ними зачастую нужны так же иные. Это не говоря уже о том, что часть тулсета (билд-сервера, скрипты, коммит хуки, etc) может не поддерживать ничего кроме Свн-а или иметь проблемы с другими системами контроля версий. Такие вещи надо выносить в artifact repository типа Nexus, как в Java делается. У нас пол-проекта С и все сторонние библиотеки так хранятся. Это уменьшило размер checkout-a ветки с порядка 5-7 гиг до порядка 100 мег (копии таких библиотек для 10+ платформ занимают дикое место). Соответственно ускорились все операции с веткой.

Это, кстати, тоже фактор, ограничивающий применение чего-либо, кроме SVN, в нашем случае — размер репозитория, из-за того, что в нем когда-то хранились бинарники, очень большой. Копировать его весь на каждую новую машину накладно, да и бессмысленно — мне вся эта история нужна, наверное, раз в день. Конечно можно, какие вопросы. Только посмотрите, что вышло из «безболезненного перехода»: надо всех научить пользоваться новой системой, поставить всем софт, рассказать про отличия, набить шишек, переделать скрипты, написать пачку новых, еще набить шишек, потратить Х часов каждого человека на вышеописанные процессы, натренировать админов, а потом, вот уже потом, сэкономить на времени апдейтов и мержей в течение хода проекта, и то не для всех членов команды, т.к. 2/3 и так не имели с этим проблем.

Встает закономерный вопрос: а есть ли у проекта время на все это, с учетом надвигающихся дедлайнов? Нередко, в силу рисков и затрат, дешевле и спокойнее остаться на том, что работает, пусть и не идеально. Что, разумеется, не отменяет возможности использовать Меркуриал/Гит на местах с Свн-ом в качестве центрального репозитория. Сторонние библиотеки — это удобно. Скачал и сразу работаешь. Если их надо отдельно ставить — это геморрой. Например за использовали вы библиотеку libXXX версии 1.4.6 локально она у вас есть, но вы не залили ее в репозиторий и тут у вас накрылся винт.

Вы заново забираете свой проект их SVN, лезите на сайт библиотеки libXXX, а его нет! Лазите по инету, а там только последняя версия этой библиотеки есть libXXX 2.0.1, которая не совместима с вашим кодом. Все, проект переписывать? ( почти реальный случай ). Если нет конфликтов содержимого (в обоих ветках поменяли одну и ту же строчку в файле) и конфликтов структуры (в одной ветке файл переименовали в одно имя, в другой ветке — в другое) то merge в git и subverson выглядит абсолютно одинакого. Не первый год уже пользуюсь и тем, и тем. Единственная известная мне разница — subversion не делает автоматический merge если в одной ветке файл был переименован/перимещен, а в другой изменен.

Я пока не разобрался почему так (выше написали, что информацию об перемещении subversion все таки хранит) — но это не то чтобы очень часто случается.