В Subversion это настолько естественно, что этого не замечаешь.
Самый простой способ:
обновиться
поменять два файла
закоммитить первый файл
закоммитить второй файл — в этом месте рабочая копия уже не от последней ревизии
Но по большому счету, повторная попытка заливки нужна из-за того, что кто-то может параллельно совершить git push в ту же ветку.
Если бы мы просто вернули ошибку в случае «не fast forward», то при повторной попытке коммит мог бы пройти у пользователя, что выглядит странно. При текущем же поведении, если первая попытка закоммитить не прошла, то второй раз пытаться не имеет смысла — будет та же ошибка.
Subversion не выдавал в таких случаях ошибку. Для коммита через Subversion достаточно, чтобы изменения коммита не пересекалось с другими изменениями. При этом не обязательно, чтобы рабочая копия была обновлена до последней версии.
Принцип «кто последний, тот и прав», как минимум, сомнителен. В нашем случае с одними и теми же данными могут работать разные люди. Потеря изменений «втихую» недопустима, так как обнаружится через очень продолжительное время.
Реализация своего интерфейса не рассматривалась по той причине, что у многих программ есть готовая интеграция с Perforce и Subversion, но нет интеграции с Git. Подменяя интерфейс на стороне сервера мы автоматически используем встроенную интеграцию без необходимости допиливать каждый инструмент для использования с Git-ом.
Именно по этому программисты и любят Git.
Выбор клиента тут имеет второстепенное значение.
Проблема в другом: у дизайнеров файлы бинарные и слияние не возможно в принципе. Из-за этого все телодвижения с локальными ветками теряют смысл и превращаются в обузу. Локальные коммиты при этом становятся вредными, так как только увеличивают вероятность конфликта.
Я подозреваю, что гиганты софтоиндустрии им пользуются не от того, что он платный, а от того, что он появился до Subversion, Git, Mercurial и пр.
На момент его выхода, если не ошибаюсь, из систем контроля версий были только SourceSafe и CVS.
В любом случае, чтобы составить представление о системе контроля версий с ней нужно поработать хотя бы месяц :)
SVNKit хороший продукт и его существование значительно сократило нам объем работы.
Но SubGit использует потенциально опасную концепцию мастер-мастер репликации.
Сама идеология мастер-мастер репликации порождает кучу вопросов:
как делать коммит-хуки?
какой репозиторий первичен?
как происходит одновременный коммит через Git и Subversion?
как делать резервную копию без остановки сервиса?
как восстановится соответствие репозиториев друг-другу, если в час X отключить питание?
что делать, если один из репозиториев умрет?
К сожалению, посмотреть на его исходный код, чтобы получить ответы на эти вопросы, мы не можем. При этом есть четкое понимание, что добиться работоспособности этой связки очень и очень не просто.
Ощущение от работы с ним сложилось такое: оно работает, но как — не понятно.
То есть для меня это магическая черная коробка, от которой не понятно, что ожидать в будущем.
Мой опыт показывает, что Git быстрее Subversion даже в пределах локальной сети. У меня есть подозрения о причинах этого явления, но это тема отдельной дискуссии.
Хотя создание реплики Subversion через svnsync действительно снижает остроту проблемы.
Просто получите ещё одну рабочкую копию с помощью `svn checkout` и обновите её до любой ревизии которую хотите просмотреть.
Допустим:
я обновился
поменял 100500 файлов
попытся закоммитить, но не смог — меня кто-то опередил
обновился
мерж 100500 файлов
запутался и накосячил при мерже
В этой ситуации Subversion не позволяет откатиться к состоянию до начала мержа.
svn checkout даст мне возможность откатиться до начала изменения 100500 файлов, но от этого, обычно, не легче.
4 Гб это смешной размер. Он даже много меньше моей рабочей копии.
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
Самое страшное, что может произойти: расхождение содержимого репозиториев.
Пока нет никаких объяснений почему это не может произойти, как это обнаружить и что в этой ситуации делать.
Самый простой способ:
Но по большому счету, повторная попытка заливки нужна из-за того, что кто-то может параллельно совершить git push в ту же ветку.
Если бы мы просто вернули ошибку в случае «не fast forward», то при повторной попытке коммит мог бы пройти у пользователя, что выглядит странно. При текущем же поведении, если первая попытка закоммитить не прошла, то второй раз пытаться не имеет смысла — будет та же ошибка.
В нашем случае это поведение сохраняется.
Но пока не понятно, по каким принципам он работает, я бы его использовать не рискнул.
Реализация своего интерфейса не рассматривалась по той причине, что у многих программ есть готовая интеграция с Perforce и Subversion, но нет интеграции с Git. Подменяя интерфейс на стороне сервера мы автоматически используем встроенную интеграцию без необходимости допиливать каждый инструмент для использования с Git-ом.
Выбор клиента тут имеет второстепенное значение.
Проблема в другом: у дизайнеров файлы бинарные и слияние не возможно в принципе. Из-за этого все телодвижения с локальными ветками теряют смысл и превращаются в обузу. Локальные коммиты при этом становятся вредными, так как только увеличивают вероятность конфликта.
На момент его выхода, если не ошибаюсь, из систем контроля версий были только SourceSafe и CVS.
В любом случае, чтобы составить представление о системе контроля версий с ней нужно поработать хотя бы месяц :)
Но SubGit использует потенциально опасную концепцию мастер-мастер репликации.
Сама идеология мастер-мастер репликации порождает кучу вопросов:
К сожалению, посмотреть на его исходный код, чтобы получить ответы на эти вопросы, мы не можем. При этом есть четкое понимание, что добиться работоспособности этой связки очень и очень не просто.
Ощущение от работы с ним сложилось такое: оно работает, но как — не понятно.
То есть для меня это магическая черная коробка, от которой не понятно, что ожидать в будущем.
Хотя создание реплики Subversion через svnsync действительно снижает остроту проблемы.
Решение: https://github.com/slonopotamus/wingit/releases
Допустим:
В этой ситуации Subversion не позволяет откатиться к состоянию до начала мержа.
svn checkout даст мне возможность откатиться до начала изменения 100500 файлов, но от этого, обычно, не легче.
Там безумные объемы и нет таких жестких требований к соответствию данных и кода.
Разработка по остаточному принципу. Задействовано два человека.
Мы не знаем, на них ответов и это нас останавливает.
Но, справедливости ради, пока мы тыкали в него палочкой, он вел себя стабильно.
Есть не официальная сборка: github.com/slonopotamus/wingit
Но, такова жизнь: пока не появится в команде хоть кто-то, кто с ним работал ранее, вероятность его использования минимальна.
Буду очень признателен, если предоставите хоть какой-то внятный обзор на тему «почему Perforce — хорошо».
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
В конечном счете, git-as-svn крутится на машине с gitlab-ом и все счастливы.