Альтернативные / множественные сопоставления структуры каталогов в репозитории git

Question

Я управляю большим (23 000 LOC для include / src, 5000 LOC для образцов) мультиплатформенной библиотекой кода ANSI C, используемой во всем: от 8-разрядного встроенного процессора с 32 КБ флэш-памяти до настольного ПК Окна. Эта база кода будет продолжать расти, и мы будем добавлять к ней больше платформ.

В настоящее время я использую Subversion для его поддержки, но компания переходит на git для всего контроля версий.

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

Например, одна платформа может иметь следующую структуру:

• ЦСИ / Foo
• SRC / Foo / платформа
• ЦСИ / alternate_name_for_bar
• ЦСИ / Baz
• включить / Foo
• включать / бар
• образцы / Foo

В то время как другой может быть таким:

• Lib / Ли / Foo
• Lib / Ли / Foo / платформа
• Lib / Blah / bar
• Lib / Blah / foo / baz (запишите baz как подкаталог foo вместо того же уровня)
• include / foo
• включить / бар
• include / baz
• Образцы / Foo
• Образцы / Foo / общий

и хранилище:

• ЦСИ / Foo
• SRC / бар
• ЦСИ / Baz
• src / platform1 (отображается на foo / platform на источнике платформы 1)
• src / platform2 (отображается на foo / platform на источнике платформы 2)
• src / platform3 (отображается на foo / platform на источнике платформы 3)
• включить / Foo
• включать / бар
• включать / Baz
• samples / platform1 (отображает образцы / foo на платформе 1)
• samples / platform2 (отображает образцы / foo на платформе 2)
• samples / platform3 (отображает образцы / foo на платформе 3)

У меня есть гибкость в структуре каталогов репозитория, но я бы хотел что-то, что имеет смысл и его легко поддерживать. Я также хочу хранить все в одном репозитории, поскольку набор изменений может потенциально повлиять на один из файлов заголовка в include, несколько файлов в src и несколько примеров программ.

В Subversion я мог использовать svn: externals для сопоставления каталогов. В репозитории есть все файлы в корневом каталоге с именем master, а затем дополнительные корневые каталоги для каждой платформы, использующей svn: externals для сопоставления файлов / каталогов с master с любым макетом, требуемым для данной платформы.

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

Большая часть встроенной разработки происходит в Windows, поэтому символические ссылки не будут работать для отображений каталогов.

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

Answer 1

Я бы предложил субмодули для общих модулей (поддеревьев), как только цикл управления версиями будет достаточно независим от остального хранилища.

Еще одна идея, о которой стоит упомянуть, ИМХО, - это ветки тем.Сохраняйте некоторые специфичные для платформы настройки в ветвях тем, чтобы их можно было «наложить» поверх центральной ветки, находящейся в разработке.

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

Я бы, конечно, держал все в одном репо;Если нужно, вы можете

• избегать подмодулей git
• избегать символических ссылок

и по-прежнему иметь «логически» связанные поддеревья с помощью небольшого количества сценариев:

См. git read-tree, например,

git read-tree --prefix=externals/ origin/3rdparty:i386/externals
git read-tree --prefix=samples/ origin/samples

( обратите внимание, как origin/3rdparty:i386/externals является прямой ссылкой на поддерево определенного ссылки, как подробно описано в man git-rev-spec)

Пока вы сохраняете externals/ и samples/ в .gitignore для обычных веток, содержащих такие динамически связанные поддеревья , у вас не возникнет особых проблем (относитесь к ним как к readonly в их связанной форме, во многом как svn externals).

Answer 2

Итак, я наконец-то перешел с Subversion на git и, согласно комментарию @ peachykeen к моему вопросу, я смог использовать точек соединения для своих отображений каталогов. Я только что создал небольшой командный файл, который перебрал пары ссылок и целей и использовал rmdir для удаления старых ссылок и mklink /j для создания новых.

@echo off

:: Expand variables at execution time rather than at parse time.
setlocal EnableDelayedExpansion

SET MAPPING=    ^
    include\foo:include\foo ^
    include\bar:include\bar ^
    include\baz:include\baz ^
    src\foo:Lib\Blah\foo    ^
    src\bar:Lib\Blah\bar    ^
    src\baz:Lib\Blah\baz    ^
    src\util:Lib\Blah\foo\util  ^
    src\platform:Lib\Blah\foo\platform  ^
    samples\platform:Samples\foo    ^
    samples\common:Samples\foo\common   ^
    test:Test\foo

set PLATFORM=..\..\
set DRIVER=..\

for %%M in (%MAPPING%) do (
  for /f "tokens=1,2 delims=:" %%a in ("%%M") do (
    set SRC=%%a
    set DST=%%b
    if exist %PLATFORM%!DST! rmdir %PLATFORM%!DST!
    mklink /j %PLATFORM%!DST! %DRIVER%!SRC!
  )
)

Это может даже работать с драйвером как подмодуль git. Просто необходимо запустить пакетный файл один раз, чтобы установить соединения.