解决失败的“git svn clone” （需要完整的历史） [英] Work-around for failing "git svn clone" (requiring full history)

问题描述

我想将一个Subversion版本库子目录（在这里用 module 表示）转换成一个完整历史的git版本库。在Subversion版本库的历史中有很多 svn copy 操作（Subversion人称它们为分支）。发布政策是，在每个发行版或其他分支创建之后，旧的URL不会被使用，新的URL替换旧的URL以包含作品。

最佳地，通过我的阅读，它似乎应该这样做：

pre $ git svn clone --username = mysvnusername - file = authors.txt \
- follow-parent \
http：// svnserver / svn / src / branches / x / y / apps /模块模块

（其中 branches / x / y / 描述了最新的分支）。但是我得到一个错误，看起来像这样：

  W：忽略来自SVN的错误，路径可能不存在:(文件系统没有项目：'/ svn / src /！svn / bc / 100 / branches / x / y / apps / module'路径未找到
 W：不要对上述消息感到惊慌git- svn只是在积极寻找旧的历史。 
  

（更新：）添加选项 - 否-minimize-url 到上面并不会删除错误信息。）

目录 module 被创建和填充，但Subversion历史超过最新的 svn copy commit没有被导入（当我预期数百个时，创建的git仓库最终只有两次提交） 。

现在的问题是，如何在出现这种情况时导出完整的Subversion历史记录？

可能原因

1. 搜索错误消息，我发现： git-svn匿名签出失败，并且链接到此Subversion问题的-s
   ： http://subversion.tigris.org/issues/show_bug.cgi?id=3242

   
   
   

   我是什么rstand在我的阅读中，Subversion 1.5中的一些内容改变了客户端如何访问存储库。使用更新的Subversion时，如果没有对URL路径的某个超级目录的读取访问权限（对我来说是true， svn ls http：// svnserver / svn 失败， 403 Forbidden ），那么我们就会失败并进行一些Subversion操作。

Subversion网址也可能会导致此错误消息（由用户Owen确认）。看看他的解决方案，看看如果你的 git svn clone 没有为同一个resson失败，他是如何解决这个问题的。
Dejay Clayton在他的回答中显示，如果分支和标签svn网址中最深的子目录组件被同名（例如 ... / tags / release / 1.0.0 和 ... / branches / release-candidates / 1.0.0 ），那么这个错误就可能发生。

解决方案

我在分支或标记中拥有相同名称的子目录时遇到了此问题。 b $ b

例如，我有标签 candidates / 1.0.0 和 releases / 1.0.0 ，这导致了记录错误，因为子目录 1.0.0 出现在候选人和版本。

每 git-svn docs ：

使用多分支或--tags，git svn不会自动处理名称冲突（例如，如果来自不同路径的两个分支名称相同，或者分支和标签名称相同）。在这些情况下，使用init来设置您的Git存储库，然后在第一次读取之前编辑$ GIT_DIR / config文件，以便分支和标签与不同的名称空间相关联。

所以，当下列命令由于类似的命名 candidates 和版本而失败时标签：

  git svn clone --authors-file = .. / authors.txt --no-metadata \ 
 --trunk = / trunk --branches = / branches --tags = / candidates \ 
 --tags = / releases --tags = / tags -r 100：HEAD \ 
 --prefix = origin / \ 
 svn：//example.com：3692 / my-repos / path / to / project / 
  

以下命令序列确实有效：

  git svn init --no- metadata \ 
 --trunk = / trunk --branches = / branches --tags = / tags \ 
 --prefix = origin / \ 
'svn：//示例。 com：3692 / my-repos / path / to / project /'
 
 git config --add svn-remote.svn。 tags \ 
'path / to / project / candidates / *：refs / remotes / origin / tags / Candidates / *'
 
 git config --add svn-remote.svn.tags \ 
'path / to / project / releases / *：refs / remotes / origin / tags / Releases / *'
 
 git svn fetch --authors-file = .. / authors .txt -r100：HEAD 
  

请注意，这仅适用于<$ c中没有其他冲突$ c>分支和标签。如果有的话，我将不得不以类似的方式解决它们。

成功克隆SVN存储库后，我执行以下步骤：将SVN标签转换为GIT标签;将 trunk 转换为 master ;将其他参考转为分支;并重新定位远程路径：

 ＃将标签变为true标签
 cp -Rf .git / refs / remotes / origin / tags / * .git / refs / tags / 
 rm -Rf .git / refs / remotes / origin / tags 
 
＃对分支
 cp -Rf进行其他引用。 git / refs / remotes / origin / * .git / refs / heads / 
 rm -Rf .git / refs / remotes / origin 
 cp -Rf .git / refs / remotes / * .git / refs / heads /＃可能会丢失;没关系
 rm -Rf .git / refs / remotes 
 
＃将'trunk'更改为'master'
 git checkout trunk 
 git branch -d master 
 git branch -m trunk master 
  

I want to convert a Subversion repository sub-directory (denoted by module here) into a git repository with full history. There are many svn copy operations (Subversion people call them branches) in the history of my Subversion repository. The release policy has been that after each release or other branches created, the old URL is left unused and the new URL replaces the old one for containing the work.

Optimally, by my reading, it seems like this should do the trick:

$ git svn clone --username=mysvnusername --authors-file=authors.txt \
    --follow-parent \
    http://svnserver/svn/src/branches/x/y/apps/module module

(where branches/x/y/ depicts the newest branch). But I got an error, which looks something like this:

W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/src/!svn/bc/100/branches/x/y/apps/module' path not found
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.

(Update: Adding option --no-minimize-url to the above does not remove the error message.)

The directory module get created and populated, but the Subversion history past the newest svn copy commit is not imported (the git repository created ends up having just two commits when I expected hundreds).

The question is, how to export the full Subversion history in the presence of this situation?

Possible Cause

1. Searching for the error message, I found this: git-svn anonymous checkout fails with -s which linked to this Subversion issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3242

   What I understand by my reading, something in Subversion 1.5 changed about how the client accesses the repository. With newer Subversion, if there is no read access to some super directory of the URL path (true for me, svn ls http://svnserver/svn fails with 403 Forbidden), then we fail with some Subversion operations.

2. Jeff Fairley in his answer points out that spaces in the Subversion URL might also cause this error message (confirmed by user Owen). Have a look at his solution to see how he solved the case if your git svn clone is failing for the same resson.

3. Dejay Clayton in his answer reveals that if the deepest subdirectory components in branch and tag svn urls are equally named (e.g. .../tags/release/1.0.0 and .../branches/release-candidates/1.0.0) then this error could occur.

解决方案

I ran into this problem when I had identically-named subdirectories within branches or tags.

For example, I had tags candidates/1.0.0 and releases/1.0.0, and this caused the documented error because subdirectory 1.0.0 appears within both candidates and releases.

Per git-svn docs:

When using multiple --branches or --tags, git svn does not automatically handle name collisions (for example, if two branches from different paths have the same name, or if a branch and a tag have the same name). In these cases, use init to set up your Git repository then, before your first fetch, edit the $GIT_DIR/config file so that the branches and tags are associated with different name spaces.

So while the following command failed due to similarly named candidates and releases tags:

git svn clone --authors-file=../authors.txt --no-metadata \
    --trunk=/trunk --branches=/branches --tags=/candidates \
    --tags=/releases --tags=/tags -r 100:HEAD \
    --prefix=origin/ \
    svn://example.com:3692/my-repos/path/to/project/

the following sequence of commands did work:

git svn init --no-metadata \
    --trunk=/trunk --branches=/branches --tags=/tags \
    --prefix=origin/ \
    'svn://example.com:3692/my-repos/path/to/project/'

git config --add svn-remote.svn.tags \
    'path/to/project/candidates/*:refs/remotes/origin/tags/Candidates/*'

git config --add svn-remote.svn.tags \
    'path/to/project/releases/*:refs/remotes/origin/tags/Releases/*'

git svn fetch --authors-file=../authors.txt -r100:HEAD

Note that this only worked because there were no other conflicts within branches and tags. If there were, I would have had to resolve them similarly.

After successfully cloning the SVN repository, I then executed the following steps in order to: turn SVN tags into GIT tags; turn trunk into master; turn other references into branches; and relocate remote paths:

# Make tags into true tags
cp -Rf .git/refs/remotes/origin/tags/* .git/refs/tags/
rm -Rf .git/refs/remotes/origin/tags

# Make other references into branches
cp -Rf .git/refs/remotes/origin/* .git/refs/heads/
rm -Rf .git/refs/remotes/origin
cp -Rf .git/refs/remotes/* .git/refs/heads/ # May be missing; that's okay
rm -Rf .git/refs/remotes

# Change 'trunk' to 'master'
git checkout trunk
git branch -d master
git branch -m trunk master

这篇关于解决失败的“git svn clone” （需要完整的历史）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！