Поиск…
замечания
Клонирование действительно больших хранилищ SVN
Если история SVN-репо действительно действительно большая, эта операция может занять несколько часов, так как git-svn нуждается в восстановлении полной истории репо SVN. К счастью, вам нужно только клонировать SVN repo один раз; как и в любом другом репозитории git, вы можете просто скопировать папку репо другим сотрудникам. Копирование папки на несколько компьютеров будет быстрее, чем просто клонирование больших SVN-репозитов с нуля.
О коммиттах и SHA1
Ваши местные git-коммиты будут переписаны при использовании команды git svn dcommit . Эта команда добавит текст в сообщение git commit, ссылающееся на версию SVN, созданную на сервере SVN, что очень полезно. Однако добавление нового текста требует изменения существующего сообщения фиксации, которое фактически не может быть выполнено: git commits не поддаются обработке. Решением является создание нового коммита с тем же содержимым и новым сообщением, но в любом случае это технически новая фиксация (т. Е. SHA1 команды git commit)
Поскольку git-фиксации, созданные для git-svn, являются локальными, идентификаторы SHA1 для git-коммитов отличаются между каждым репозиторием git! Это означает, что вы не можете использовать SHA1 для ссылки на фиксацию от другого лица, потому что тот же фиксат будет иметь различный SHA1 в каждом локальном репозитории git. Вы должны полагаться на номер версии svn, добавленный к сообщению о фиксации, когда вы нажимаете на сервер SVN, если вы хотите ссылаться на фиксацию между различными копиями репозитория.
Вы можете использовать SHA1 для локальных операций, хотя (показать / отличить конкретную фиксацию, выбор вишней и сброс и т. Д.),
Поиск проблемы
Команда git svn rebase выдает ошибку несоответствия контрольной суммы
Команда git svn rebase выдает ошибку, подобную этой:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
Решение этой проблемы сбрасывается svn на ревизию, когда поврежденный файл был изменен в последний раз, и выполните git svn fetch, чтобы восстановить историю SVN. Команды для выполнения сброса SVN:
- git log -1 -
<path_to_file>(скопируйте номер версии SVN, который появляется в сообщении фиксации) - git svn reset
<revision_number> - git svn fetch
Вы сможете снова и снова извлекать данные из SVN
Файл не найден в commit Когда вы пытаетесь извлечь или вытащить из SVN, вы получите ошибку, подобную этой
<file_path> was not found in commit <hash>
Это означает, что ревизия в SVN пытается изменить файл, который по какой-то причине не существует в вашей локальной копии. Лучший способ избавиться от этой ошибки - заставить fetch игнорировать путь к этому файлу, и он будет обновлен до статуса в последней версии SVN:
-
git svn fetch --ignore-paths <file_path>
Клонирование хранилища SVN
Вам необходимо создать новую локальную копию репозитория с помощью команды
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Если ваш SVN-репозиторий соответствует стандартным макетам (соединительные линии, ветви, теги), вы можете сохранить некоторые типизации:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone проверяет каждую ревизию SVN один за другим и делает git-фиксацию в вашем локальном репозитории, чтобы воссоздать историю. Если репозиторий SVN имеет много коммитов, это займет некоторое время.
Когда команда будет завершена, у вас будет полноценный git-репозиторий с локальной ветвью, называемой master, которая отслеживает ветвь соединительной линии в репозитории SVN.
Получение последних изменений из SVN
Эквивалентом git pull является команда
git svn rebase
Это извлекает все изменения из репозитория SVN и применяет их поверх ваших локальных коммитов в вашей текущей ветке.
Вы также можете использовать команду
git svn fetch
для извлечения изменений из репозитория SVN и переноса их на локальную машину, но без применения их к локальной ветке.
Нажатие локальных изменений в SVN
Команда
git svn dcommit
создаст ревизию SVN для каждого из ваших локальных git-коммитов. Как и в случае с SVN, ваша локальная история git должна быть синхронизирована с последними изменениями в репозитории SVN, поэтому, если команда не работает, попробуйте выполнить сначала git svn rebase .
Работа на местном уровне
Просто используйте локальный репозиторий git как обычное git-репо с обычными командами git:
-
git add FILEиgit checkout -- FILEЧтобы создать / отключить файл -
git commitЧтобы сохранить изменения. Эти коммиты будут локальными и не будут «толкаться» к репо SVN, как в обычном репозитории git -
git stashиgit stash popПозволяет использовать приступы -
git reset HEAD --hardвсе ваши локальные изменения -
git logДоступ ко всей истории в репозитории -
git rebase -iчтобы вы могли свободно переписывать свою местную историю -
git branchиgit checkoutдля создания локальных ветвей
Как указано в документации git-svn, «Subversion - это система, которая намного менее сложна, чем Git», поэтому вы не можете использовать всю полноту git, не испортив историю на сервере Subversion. К счастью, правила очень просты: держите историю линейной
Это означает, что вы можете сделать почти любую операцию git: создание ветвей, удаление / переупорядочение / раздачу коммитов, перемещение истории вокруг, удаление коммитов и т. Д. Все, кроме слияния . Если вам нужно реинтегрировать историю локальных ветвей, вместо этого используйте git rebase .
Когда вы выполняете слияние, создается слияние. Особая вещь о слиянии заключается в том, что у них есть два родителя, и это делает историю нелинейной. Нелинейная история будет путать SVN в том случае, если вы «нажмете» фиксацию слияния в репозиторий.
Однако не беспокойтесь: вы ничего не сломаете, если вы «нажмете» фиксацию слияния git на SVN . Если вы это сделаете, когда коммит git merge будет отправлен на сервер svn, он будет содержать все изменения всех коммитов для этого слияния, поэтому вы потеряете историю этих коммитов, но не изменения в коде.
Обработка пустых папок
git не распознает концепцию папок, он просто работает с файлами и файлами. Это означает, что git не отслеживает пустые папки. SVN, однако, делает. Использование git-svn означает, что по умолчанию любые изменения, которые вы делаете с пустыми папками с git, не будут распространяться на SVN .
Использование флага --rmdir при выпуске комментария исправляет эту проблему и удаляет пустую папку в SVN, если вы локально удаляете последний файл внутри него:
git svn dcommit --rmdir
К сожалению, он не удаляет существующие пустые папки : вам нужно сделать это вручную.
Чтобы не добавлять флаг каждый раз, когда вы выполняете dcommit, или играть в него безопасно, если вы используете инструмент git GUI (например, SourceTree), вы можете установить это поведение по умолчанию с помощью команды:
git config --global svn.rmdir true
Это изменяет ваш файл .gitconfig и добавляет следующие строки:
[svn]
rmdir = true
Чтобы удалить все необработанные файлы и папки, которые должны быть пустыми для SVN, используйте команду git:
git clean -fd
Обратите внимание: предыдущая команда удалит все необработанные файлы и пустые папки, даже те, которые должны отслеживаться SVN! Если вам нужно создать агацию пустых папок, отслеживаемых SVN, используйте команду
git svn mkdirs
В практике это означает, что если вы хотите очистить свое рабочее пространство от неиспользуемых файлов и папок, вы всегда должны использовать обе команды для воссоздания пустых папок, отслеживаемых SVN:
git clean -fd && git svn mkdirs