Использование тегов - вопрос от бывшего пользователя CVS

Question

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

Я использовал CVS в основном для исходного кода, но я также использовал его для других типов файлов. Одним из приложений, для которого я использовал CVS и для которого теперь хочу использовать Git, является контроль версий чертежей для номеров деталей.

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

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

Есть ли лучшее решение для установки чего-то подобного в Git? Есть ли другой тип тега, который я могу применить только к выбранным файлам? Есть ли способ клонировать все хранилища одной командой?

Спасибо за помощь!

Answer 1

Я думаю, что мне придется клонировать каждый репозиторий вручную ....

Вы должны клонировать каждый репозиторий.

Вам не нужно делать это вручную . Git использует внутри себя язык команд сценариев, и, следовательно, все установки Git имеют его. (Во многих системах он уже есть: «оболочка» ( оболочка ) или /bin/sh, а иногда bash.) Тогда все, что вам нужно, - это список репозиториев для клон и небольшой кусочек скрипта:

for i in $(cat repo-list); do git clone ${baseurl}/$i; done

В общем, когда у вас есть хранилище, вам никогда не нужно повторно клонировать: вы просто сохраняете хранилище и запускаете на нем git fetch как целесообразно, если и когда кто-то обновил репозиторий, из которого был сделан этот клон. Таким образом, вышеприведенное l oop не так уж и полезно, но:

for i in $(cat repo-list); do (cd $i && git fetch); done

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

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