Question

我通过git-svn镜像的svn存储库更改了URL。

在vanilla svn中你只需svn switch --relocate old_url_base new_url_base。

如何使用git-svn执行此操作？

只需更改配置文件中的svn url即可。

Answer 1

这很好地处理了我的情况：

https://git.wiki.kernel.org/index.php/GitSvnSwitch

我使用file://协议克隆，并希望切换到http://协议。

很有可能在url的{{1}}部分编辑[svn-remote "svn"]设置，但就其自身而言这不起作用。通常，您需要遵循以下程序：

将svn-remote .git/config设置切换为新名称。
运行url。这需要从svn！
将svn-remote git svn fetch设置更改回原始网址。
运行url以执行本地rebase（包含上次提取操作所带来的更改）。
将svn-remote git svn rebase -l设置更改回新网址。
现在，url应该再次运作。

喜欢冒险的灵魂可能想尝试--rewrite-root。

Answer 2

您可以查看以下内容是否正常：

如果配置文件（svn-remote.svn.rewriteRoot）中不存在.git/config：
```
git config svn-remote.svn.rewriteRoot <currentRepositoryURL>
```
如果配置文件中不存在svn-remote.svn.rewriteUUID：
```
git config svn-remote.svn.rewriteUUID <currentRepositoryUUID>
```
currentRepositoryUUID可以从.git/svn/.metadata获得。
git config svn-remote.svn.url <newRepositoryURL>

Answer 3

不幸的是，这些答案中的大多数链接都不起作用，因此我将复制git wiki中的一些信息以供将来参考。

这个解决方案对我有用：

修改svn-remote中的url fetch（或.git/config路径）以指向新的域/ URL /路径
运行git git svn fetch。 这需要从svn获取至少一个新版本！
如果您现在尝试git svn rebase，则会收到如下错误消息：
```
Unable to determine upstream SVN information from working tree history
```
我认为这是因为git svn因为在获取之前您的最新提交将指向旧路径git-svn-id这一事实而感到困惑，旧路径与.git/config中的路径不匹配。 {1}}。
要解决此问题，请将svn-remote url（或fetch路径）更改回原始域/网址/路径
现在再次运行git svn rebase -l以使用上次提取操作所带来的更改来执行本地rebase。这次将工作，显然是因为git svn不会被新头的git-svn-id与{{1}中的.git/config不匹配这一事实所混淆}}
最后，将svn-remote url（或fetch路径）更改回新域/网址/路径
此时git svn rebase应该再次运作！

找到了原始信息here。

Answer 4

Git svn严重依赖svn网址。从svn导入的每个提交都有git-svn-id，其中包含svn URL。

有效的重定位策略是在新存储库上调用git-svn clone并将更改合并到新的关闭上。有关更详细的过程，请参阅此文章：

http://www.sanityinc.com/articles/relocating-git-svn-repositories

Answer 5

`git filter-branch`

取自This script的

a blog entry对我有用。提供旧的和新的repo URL作为参数，就像svn switch --relocate。

一样

脚本调用git filter-branch来替换提交消息中的git-svn-id中的Subversion URL，更新.git/config，并通过使用{{1}重新创建git-svn元数据来更新它们}}。虽然git svn rebase可能是更强大的解决方案，但git svn clone方法对于大型存储库（小时与天数）的工作速度要快得多。

filter-branch

Answer 6

`git_fast_filter`

然而比git-filter-branch更快（即分钟而不是几小时），但精神上相似，就是使用git_fast_filter。但是，这需要更多的编码，并且不存在整齐的现成包装解决方案。与git-filter-branch相比，这将从旧创建一个 new repo。假设master指向最后一个SVN提交。

从Gitorious repo克隆git_fast_filter。
在基于this Gist克隆git_fast_filter的同一目录中创建Python脚本，使用chmod +x设置可执行位。调整旧的和新的存储库路径。（脚本的内容也粘贴在下面。）
使用git init初始化新的目标存储库，将工作目录更改为此新存储库。

执行以下管道：

(cd path/to/old/repo && git-fast-export --branches --tags --progress=100) | \
    path/to/git_fast_filter/commit_filter.py | git-fast-import

将.git/config中的其他相关文件以及旧仓库中的其他相关文件复制到新的仓库中。
删除.git/info。
让.git/svn了解新版本号映射
1. 执行git-svn
  - 您的git-svn遥控器可能与git branch refs/remotes/git-svn master不同，请咨询refs/remotes/git-svn，.git/config部分
2. 执行svn-remote。如果这个命令冻结了，那就错了。它应该重建版本号映射。
3. 删除假分支git svn info，它将由refs/remotes/git-svn重新创建
通过致电git-svn进行同步。

以下是git svn rebase的内容，并根据需要替换commit_filter.py和IN_REPO的值：

OUT_REPO

Answer 7

上述git svn rebase -l解决方案对我不起作用。我决定采用不同的方式：

将旧SVN repo克隆到git repo old并将新SVN克隆到git repo new
将old提取到new
- cd new
- git fetch ../old
- git tag old FETCH_HEAD
在new之上重新old（应该会成功，因为new根目录中的树和old的提示相同）
- git checkout master（假设master分支指向SVN头部。这是干净克隆的情况;否则在开始之前dcommit。）
- git rebase --root --onto old
重建new的git-svn元数据以考虑rebase
- git update-ref --no-deref refs/remotes/git-svn master（根据克隆方式调整远程引用，例如refs/remotes/svn/trunk）
- rm -r .git/svn
- git svn info

Answer 8

根据对这个问题的一些其他回答，我提出了一个处理git-svn重定位的Ruby脚本。您可以在https://gist.github.com/henderea/6e779b66be3580c9a584找到它。

它处理重定位而不检查另一个副本，它甚至处理一个或多个分支中存在未推送更改的情况（因为这会破坏常规逻辑）。它使用git filter-branch答案中的东西（对于主逻辑）和从repo的一个实例复制分支到另一个实例的答案（用于复制未推送更改的分支）。

我一直在使用它来重新定位我工作的一堆git-svn repos，这个版本的脚本（我经历过无数次迭代）似乎对我有用。它不是超快，但似乎确实处理了我遇到的所有情况，并导致完全重新定位的回购。

该脚本为您提供了在进行任何更改之前创建repo副本的选项，因此您可以使用此选项来创建备份。如果您在任何分支中有未推送的更改，则需要创建副本。

该脚本不使用普通MRI Ruby安装中未包含的任何gem或其他库。它确实使用了MRI中包含的readline和fileutils库。

希望我的剧本对其他人有用。随意更改脚本。

注意：我只在OS X 10.10 Yosemite上使用git 2.3.0 / 2.3.1和Ruby 2.2.0测试了这个脚本（因为那是我使用的环境），但我会期望它也适用于其他环境。但不保证Windows。

git-svn：什么相当于`svn switch --relocate`？

8 个答案:

`git filter-branch`

`git_fast_filter`