Возможно, это необычно, поэтому позвольте мне установить сцену:Управляйте источником при git и svn одновременно - это имеет смысл?
У нас есть репозиторий SVN, содержащий нашу историю проекта - встроенную систему на базе Linux. Репо SVN содержит ядро Linux, U-Boot, busybox и т. Д. Источники и все наши собственные приложения, файловую систему и т. Д.
Ядро Linux у нас есть старое и жесткое, и я работаю над портированием на магистраль, которая находится в активной разработке для нашей платформы. Я делаю работу со стороны ядра под git и торговыми патчами с «Сообществом».
Я мог бы заставить все работать и делать снимок источников ядра и выгружать его в SVN, но я хотел бы сохранить возможность получать обновления, иметь локальные ветви и управлять патчами с помощью git. Я мог бы хранить две копии ядра, каждый из которых управлялся каждым SCM, но это было бы немного беспорядочно. Существуют также риски разработки и тестирования с использованием источников ядра, управляемых с помощью git, и забывания вносить эти изменения в SVN, что приводит к нарушению версий SVN, когда неядерные источники не синхронизированы.
Миграция всего проекта на git не является вариантом. Управление только источником ядра с помощью git и наличием связки скриптов и хранимых хэшей в SVN возможно, но лучше всего иметь единую историю/отличную способность от SVN для всего проекта.
То, что я рассматриваю, пытается одновременно управлять источниками ядра как SVN, так и git, в том же каталоге.
Как ядро dev, я бы использовал git и выполнял SVN-фиксацию для внутреннего использования, когда все выглядело хорошо. Для других внутренних пользователей они смогут получить все последовательные источники с одной проверкой SVN, увидеть единую историю и внести изменения в источники ядра в SVN. Позже я или другой человек, использующий git, может обновить SVN до этих изменений и передать их git по мере необходимости.
Некоторое удовольствие от получения git, чтобы игнорировать файлы .svn и наоборот, должно быть выполнено. Кроме того, я не совсем уверен, как можно взять обычную проверку SVN и сказать git, чтобы начать управлять поддеревом ядра, но я уверен, что у git есть некоторые неясные варианты швейцарских армейских ножей.
Так что это моя идея. Это означает, что большинству сотрудников не нужно беспокоиться о git, и мы можем спокойно игнорировать git и развиваться позже, когда это необходимо.
Вопрос в том, действительно ли кто-нибудь сделал что-то подобное, как это получилось, или какие альтернативные решения вы придумали?
После этого я сейчас занимаюсь этим, и он работает хорошо. – blueshift
Что делать, если вам нужно клонировать эту установку на другой компьютер? Например, если у меня есть каталог под управлением git, то добавьте его в svn с соответствующими игнорируемыми значениями, но затем захотите же настроить на другой машине. Должен ли я клонировать git repo, а затем попытаться проверить svn repo в этом каталоге? С другой стороны? –
Выяснилось, что вы можете делать то, что я попросил, выполнив git clone, затем «svn checkout --force», чтобы объединить два репозитория. –