在我工作的地方，我们对项目采用了一种略微非常规的svn repo布局。它看起来像这样：
project/
branches/
tags/
trunk/
utils/
我们是一家非常小的公司，我们的大部分项目都相对较小。每个开发项目的开发人员通常都会检查整个repo，并且有一些post-commit钩子可以防止一次更改多个分支。 utils文件夹包含一些对每个项目都有用的脚本，包括在首次提取repo时为开发人员本地机器自动创建HOSTS和apache vhost指令，一些svn快捷方式以及一些项目特定的东西。
这种布局对我们很有用。
现在，我想使用git-svn，但是我无法弄清楚开发人员可以访问的utils文件夹的添加方式，无论他们正在使用哪个分支，都会转换为git。
解决这个问题的唯一可行办法就是git svn clone整个回购，然后为git svn fetch --ignore-paths设置一些别名，这样如果我是在特定分支上工作，我不会从其他分支获取更改，然后为每个远程分支创建本地主题分支。
这样做的缺点是主要是必须设置这些别名 - 在我看来这是一个有点丑陋的解决方案 - 但它似乎至少应该起作用。至于使用git-svn的分支检测/集成功能，我不认为它可以在这里工作，因为检出分支是“破坏性的”，并且utils文件夹存在于repo的顶层。 / p>
那么，是否有更好的方法将git-svn内容限制在代表当前分支的目录中，或者是一种更简洁的方式来处理这种情况？
答案 0 :(得分：1)
我开始写出如何将utils /作为分支区域暴露给git svn的响应，然后意识到它根本不是一个分支;它完全是一个不同的项目。 I.E.，此树下的代码不与分支，标签和主干树下的代码共享任何祖先。由于每个人都在检查整个存储库，我想知道合并是如何进行的，但这是另一个故事。
如果你在这里使用git-svn，你可能会像处理标准回购一样处理这个回购。您将拥有整个存储库，但您一次只能处理一个分支（这似乎是您的提交钩子正在执行的行为）。对于utils目录，您可以考虑为此创建一个单独的git svn repo。毕竟，无论如何，你都没有合并进出该区域的变化，所以除了需要定期更新另一个WC外，你真的不会失去任何其他东西。
祝你好运！答案 1 :(得分：1)
我对你的问题的主要部分没有答案，但我可能有一个问题，你必须设置“带有--ignore-paths”的别名问题。
在我工作的地方，我们执行以下操作，而不是执行git svn clone并获取所有内容：
git svn init <Svn repo url> -T trunk -b branches --ignore-paths '(ignore1|ignore2)'
git svn fetch -r 12345:HEAD
这样我们就可以获得svn存储库的浅而窄的克隆。
然后将来我们只需要这样做：
git svn fetch
在执行git rebase和git svn dcommit之前更新git svn repo以推回到svn repo。
答案 2 :(得分：0)
有史以来最新的答案，但......
除非你真的知道这是你想要的，否则我会反对使用git svn开关或等价物对你的SVN repo-root运行-s。这将导致一个非常＆＃34; un-git＆＃34;最终存储库，其中来自不同分支的代码在您创建的每个Git分支中都是重复的。 发抖
您要做的是使用-s标准布局选项，让git svn做出精美的工作，创建合适的分支及其历史。
关于utils？它的位置和您的描述表明它是一个独立版本的结构。它的变化与每个分支上发生的变化无关，否则它将按分支存储。要将它带入Git，首先应该为这个目录创建一个单独的Git克隆。然后你有几个选择：你可以a）决定它现在在Git中保持每个分支，并且只需将它检查到你关心的每个分支的HEAD中。您可能需要修复并重新标记旧/重要标签。或者b），只需将它作为一个独立版本的Git子模块引入Git，这就像它看起来那样。然后你可以在每个分支中拥有它，但集中提交它。您当然需要更新脚本以考虑新位置./utils而不是../utils。