Git-svn 可以在大型分支存储库上使用吗？
我正在尝试使用 Git 作为 SVN 存储库的前端，以便能够使用 Git 的优秀功能，例如简单分支、存储等。
问题是 SVN 存储库非常大（8,000 转）并且包含大量分支和标签（旧的和新的）。
这是一个接近标准的布局，配置包含获取、分支和标签指令。
由于最旧的分支和标签引用修订版 10，这意味着每次 svn fetch 都会读取修订版 10 及以后的整个存储库历史记录，这在慢速连接上可能需要数小时。
如果我只跟踪主干，那就没问题，但我仍然想让 git 知道新的分支和标签。
我通常会查看我所在分支上的 git log -1 并从评论中获取 SVN 修订版，因此我可以执行 git svn fetch -r7915:HEAD 或相似的。我想这就是 git svn fetch --parent 所做的。但为什么我需要这样做呢？
我在 Windows 上使用 TortoiseGit，它对 git-svn 有很好的支持，但由于 TortoiseGit 只运行 git svn fetch 我有点卡住了。
我做错了什么吗？我希望当第一个 svn clone -s 完成时，svn fetch 是一个快速的操作。
I am trying to use Git as a frontend to a SVN repository in order to be able to use Git's nice features like simple branching, stashing etc.
The problem is that the SVN repository is quite large (8,000 revs) and contains lots of branches and tags (old as well as new).
It's a near standard layout, with a config containing fetch, branches and tags directives.
Since the oldest branch and tag refers to revision 10, it means that every svn fetch reads the entire repository history from revision 10 and forward, which can takes hours on the slow connection.
If I only track trunk, then it's fine, but I still want to make git aware of new branches and tags.
I usually look at git log -1 on the branch I'm at and gets the SVN revision from the comment, so I can do git svn fetch -r7915:HEAD or similar. I guess that's what git svn fetch --parent does. But why do I need to do this?
I'm on Windows, and use TortoiseGit which has quite nice support for git-svn, but since TortoiseGit only runs git svn fetch I'm kind of stuck.
Am I doing something wrong? I expect svn fetch to be a fast operation when the first svn clone -s is complete.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
感谢您的回答。但他们并没有真正帮助我。
此命令是迄今为止最好的解决方案：
它使用 git svn log --all 来查找迄今为止获取的最高 SVN 修订号，并获取从该点开始的所有内容。
我希望 git svn fetch 能够有一个像这样的行为选项。除非 SVN 修订版发生更改，否则 git svn 没有理由每次都获取相同的修订版。
Thanks for the answers. They did not really help me, though.
This command is the best solution so far:
It uses
git svn log --allto find the highest SVN revision number fetched so far, and fetches everything from that point onwards.I wish
git svn fetchwould have an option to behave like this. Unless the SVN revisions are changed, there is no reasongit svnshould fetch the same revisions over and over each time.如果您不需要 git 存储库中的完整历史记录，我建议您查看“git + svn”方法（在下面的链接中详细介绍），而不是标准的 git-svn 集成。您最初导入 git 的速度应该非常快，因为您不会导入历史记录。
请务必阅读标题为“优点、缺点和经验教训”的部分。
https://lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx
If you do not need to have full history in the git repository, I recommend you take a look at the "git + svn" approach, detailed in the link below, instead of the standard git-svn integration. Your initial import into git should be very quick, since you will not be importing history.
Make sure to read the section entitled "Benefits, Drawbacks, and Lessons Learned".
https://lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx
您使用正确：具有大量历史记录的 Subversion 存储库的初始导入将会非常慢。
坏消息是，因为 Subversion 的分支和标签只是目录，所以 git-svn 被迫采取悲观的路线，从头开始读取每个分支，一直回到第一个修订版。是的，如果您在使用 Subversion 时遵守纪律，这将导致多次获取相同的数据，但现实世界的使用模式使这种情况不太可能发生。
晚上启动克隆，第二天早上就会看到一个漂亮的 git 仓库！
一旦你克隆了，
git svn fetch甚至会警告你：Subversion 既简单又愚蠢，所以 git 必须慢慢来。
You're using it correctly: the initial import of a Subversion repository with lots of history will be very slow.
The bad news is because Subversion's branches and tags are only directories,
git-svnis forced to take the pessimistic route of reading each branch from its head all the way back to the first revision. Yes, if you've been disciplined in your use of Subversion, this will result in many fetches of the same data, but real-world usage patterns make this an unlikely case.Start the clone in the evening and come back to a nice git repo the next morning!
Once you've cloned,
git svn fetcheven warns you:Subversion is simple and stupid, so git has to take things slowly.
SVN 存储库中有符号链接吗？
如果没有，您是否尝试过以下设置：
Do you have symlinks in the SVN repo?
If not, have you tried this setting: