Это, возможно, необычно, поэтому позвольте мне установить сцену:
У нас есть SVN-репо, содержащее нашу историю проекта - встроенную систему на базе Linux. SVN repo содержит ядро Linux, U-Boot, загружаемые файлы и т.д. Источники и все наши собственные приложения, файловую систему и т.д.
Ядро 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 и вилку позже по мере необходимости.
Вопрос в том, действительно ли кто-нибудь сделал что-то вроде этого, как это получилось, или какие альтернативные решения вы придумали?
