Скотт Чакон - Pro Git

Запустите команду git p4 clone чтобы импортировать проект "Jam" с Perforce сервера, передав ей путь к проекту в депо и директорию, в которую хотите импортировать репозиторий:

$git-p4 clone //guest/perforce_software/jam@all p4import

Importing from //guest/perforce_software/jam@all into p4import

Initialized empty Git repository in /private/tmp/p4import/.git/

Import destination: refs/remotes/p4/master

Importing revision 9957 (100%)

Конкретно этот проект имеет одну ветку, но если бы их было несколько, вы бы просто могли передать флаг --detect-branches в git p4 clone. Перечитайте раздел Ветвление для подробностей.

На данном этапе репозиторий почти готов. Если вы зайдёте в директорию p4import и выполните git log, вы увидите результат:

$git log -2

commit e5da1c909e5db3036475419f6379f2c73710c4e6

Author: giles

Date: Wed Feb 8 03:13:27 2012 -0800

Correction to line 355; change to .

[git-p4: depot-paths = "//public/jam/src/": change = 8068]

commit aa21359a0a135dda85c50a7f7cf249e4f7b8fd98

Author: kwirth

Date: Tue Jul 7 01:35:51 2009 -0800

Fix spelling error on Jam doc page (cummulative -> cumulative).

[git-p4: depot-paths = "//public/jam/src/": change = 7304]

git-p4 оставил идентификаторы в сообщениях всех коммитов. Ничего страшного нет в том, чтобы оставить всё как есть, особенно если вы захотите сослаться на номер ревизии в Perforce в будущем. Если же вы хотите убрать эти строки, теперь — прежде чем приступать к работе с репозиторием — самое время для этого. Вы можете использовать git filter-branch чтобы удалить идентификаторы из всех сообщений одним махом:

$git filter-branch --msg-filter 'sed -e "/^\[git-p4:/d"'

Rewrite e5da1c909e5db3036475419f6379f2c73710c4e6 (125/125)

Ref 'refs/heads/master' was rewritten

Если вы сейчас выполните git log, вы увидите, что SHA-1 хеши коммитов изменились, а строки git-p4 исчезли из сообщений:

$git log -2

commit b17341801ed838d97f7800a54a6f9b95750839b7

Author: giles

Date: Wed Feb 8 03:13:27 2012 -0800

Correction to line 355; change to .

commit 3e68c2e26cd89cb983eb52c024ecdfba1d6b3fff

Author: kwirth

Date: Tue Jul 7 01:35:51 2009 -0800

Fix spelling error on Jam doc page (cummulative -> cumulative).

Теперь ваш репозиторий готов к отправке на Git сервер.

Если вы переходите с TFVC на Git, вам захочется получить как можно более точную копию репозитория. Поэтому, несмотря на то, что мы рассматривали git-tfs и git-tf в предыдущих разделах, здесь мы сосредоточимся лишь на использовании git-tfs, потому что этот инструмент поддерживает ветки, чего нет в git-tf.

Это дорога в один конец. Получившийся Git репозиторий невозможно будет подключить к TFVC.

Первым делом нужно задать соответствия между пользователями. TFVC не следит за данными, сохраняемыми в поле "автор" наборов изменений, Git же ожидает увидеть там человекопонятное имя и адрес электронной почты. Вы можете получить список всех авторов с помощью консольного клиента tf:

PS> tf history $/myproject -recursive > AUTHORS_TMP

Эта команда пробегается по всем ревизиям проекта и сохраняет информацию о них в файл AUTHORS_TMP, из которого мы впоследствии вытянем пользователей (2-я колонка). Откройте этот файл и запомните начало и конец колонки с пользователями, а затем используйте следующую команду (параметр 11-20 — это и есть границы колонки с пользователями):

PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | uniq | sort > AUTHORS

Команда cut оставляет символы с 11-го по 20-й из каждой строки. Команда tail пропускает первые две строки с заголовком и ASCII-art’ом. Результат направляется в команду uniq, которая избавляется от дубликатов, её вывод сортируется и сохраняется в файл AUTHORS. Далее необходимо поработать руками: для того, чтобы git-tfs распознал записи в этом файле, они должны иметь следующий формат:

DOMAIN\username = User Name

Часть слева от знака равенства — это поле "User" из TFVC, а часть справа — соответствующий ему автор в Git.

Как только этот файл готов, необходимо сделать полную копию TFVC проекта:

PS> git tfs clone --with-branches --authors=AUTHORS https://username.visualstudio.com/DefaultCollection $/project/Trunk project_git

Затем вы, возможно, захотите избавиться от строчек с git-tfs-id в сообщениях коммитов. Следующая команда сделает это:

PS> git filter-branch -f --msg-filter 'sed "s/^git-tfs-id:.*$//g"' -- --all

Она использует утилиту sed из пакета git-bash чтобы заменить все строки, начинающиеся с git-tfs-id: на пустые, которые Git проигнорирует.

Теперь всё готово. Можете добавить новый удалённый репозиторий, отправить изменения в него и ваша команда может начинать работу с Git.

Если вы пользуетесь какой-либо другой системой контроля версий, не перечисленной выше, вам следует поискать инструмент для импорта в Сети — качественные решения доступны для CVS, Clear Case, Visual Source Safe и даже директорий с архивами. Если всё же существующие решения вам не подошли, вы пользуетесь менее известной СКВ или вам нужно больше контроля над процессом импорта — используйте git fast-import. Эта команда читает простые инструкции из потока ввода и записывает данные в Git. Создать Git-объекты таким путём намного проще, чем через низкоуровневые Git-команды или пытаясь воссоздать их вручную (обратитесь к Git изнутри за деталями). Таким образом, вы можете написать небольшой скрипт, считывающий нужную информацию из вашего хранилища и выводящий инструкции в стандартный поток вывода. Затем вы можете запустить эту программу и передать её вывод прямиком в git fast-import.

Для демонстрации, мы с вами напишем простой скрипт для импорта. Предположим, вы работаете в директории current и периодически создаёте резервные копии в директориях вида back_YYYY_MM_DD, и хотите перенести данные в Git. Структура директорий выглядит подобным образом:

$ls /opt/import_from

back_2014_01_02

back_2014_01_04

back_2014_01_14

back_2014_02_03

current

Чтобы успешно импортировать репозиторий, давайте вспомним, как Git хранит данные. Как вы наверное помните, Git по сути представляет собой связанный список ревизий, каждая из которых указывает на слепок состояния. Всё что от вас требуется, это указать fast-import'у на данные для создания слепков и порядок их применения. Итак, мы пробежимся по всем слепкам, создадим коммит для каждого из них и свяжем каждый новый коммит с предыдущим.

Как и в разделе An Example Git-Enforced Policy, мы проделаем это на Ruby, потому что это мы любим этот язык и его понять. Вы можете использовать любой другой язык — всё что требуется, это вывести нужную информацию в стандартный поток вывода. Если вы работаете на Windows, будьте особо осторожными с переводами строк: fast-import ожидает лишь символы перевода строки (LF), но не возврат каретки + перевод строки (CRLF), как принято в Windows.

Для начала зайдём в исходную директорию и определим поддиректории, содержащие состояния проекта в разные моменты времени, которые будут использованы для построения соответствующих коммитов. Вы поочерёдно посетите каждую из них и выполните команды, необходимые для экспорта. Примерно так:

last_mark = nil

# loop through the directories

Dir.chdir(ARGV[0]) do

Dir.glob( "*" ).each do|dir|

next ifFile.file?(dir)

# move into the target directory

Dir.chdir(dir) do

last_mark = print_export(dir, last_mark)