将 git-svn 与非常规的存储库布局结合使用，其中包含一个应该可供任何分支访问的目录
在我工作的地方，我们为项目使用稍微不传统的 svn 存储库布局。看起来是这样的：
project/
branches/
tags/
trunk/
utils/
我们是一家相当小的公司，我们的大多数项目都相对较小。每个从事项目的开发人员通常都会检查整个存储库，并且有一些提交后挂钩可以防止同时对多个分支进行更改。 utils 文件夹包含一些对每个项目有用的脚本，包括首次拉取存储库时为开发人员本地计算机自动创建 HOSTS 和 apache vhost 指令、一些 svn 快捷方式以及一些特定于项目的内容。
这种布局对我们来说效果很好。
现在，我想使用 git-svn，但我无法弄清楚如何添加开发人员可以访问的 utils 文件夹，无论他们正在处理哪个分支，都可以将其转换为 git。
我能想到的处理这个问题的唯一可能的方法是 git svn clone 整个存储库，然后为 git svn fetch --ignore 设置一些别名-paths 这样，如果我正在处理特定分支，我就不会从其他分支获取更改，然后为每个远程分支创建本地主题分支。
这样做的缺点是主要必须设置这些别名 - 在我看来，这是一个有点丑陋的解决方案 - 但看起来它至少应该有效。至于使用 git-svn 的分支检测/集成功能，我认为它在这里不起作用，因为检查分支是“破坏性的”，并且 utils 文件夹存在于顶层回购协议的。
那么，是否有更好的方法将 git-svn 内容限制到代表当前分支的目录，或者有更干净的方法来处理这种情况？
Where I work, we use a slightly unconventional svn repo layout for projects. It looks like this:
project/
branches/
tags/
trunk/
utils/
We're a pretty small company, and most of our projects are relatively small. Each developer working on a project usually has a checkout of the whole repo, and there are some post-commit hooks that prevent changes being made to multiple branches at once. The utils folder contains some scripts that are useful for each project, including things like automating HOSTS and apache vhost directive creation for a developers local machine when the repo is first pulled, a few svn shortcuts, and some project-specific stuff.
This layout works pretty well for us.
Now, I'd like to use git-svn, but I'm having trouble figuring out how the addition of that utils folder that is accessible to a developer regardless of what branch they're working on would translate into git.
The only possible way to deal with this that I've been able to figure out would be to git svn clone the whole repo, and then set up some aliases for git svn fetch --ignore-paths so that if I'm working on a specific branch, I wouldn't be fetching changes from other branches, and then create local topic branches for each remote branch.
The downside of doing this is mostly having to set up those aliases -- it's a somewhat ugly solution, in my opinion -- but it seems like it should work at least. As for using the branch detection/integration capabilities of git-svn, I don't think that it could work here because checking out a branch is "destructive", and that utils folder exists at the top level of the repo.
So, is there either a better way of restricting git-svn stuff to the directory that represents the current branch, or a cleaner way of handling this scenario in general?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我对你的问题的主要部分没有答案，但我可能对你的“必须使用 --ignore-paths 设置别名”问题有一个答案。
在我工作的地方，我们不是执行 git svn clone 并获取所有内容，而是执行以下操作：
然后从历史记录中的合理点获取：
这样我们就可以获得 svn 的浅层、窄克隆存储库。
那么将来我们只需要做：
在执行 git rebase 和 git svn dcommit 之前更新 git svn repo 并推送回 svn repo。
I don't have an answer for the main part of your question, but I might have one for your 'having to set up aliases with --ignore-paths' problem.
Where I work, instead of doing a
git svn cloneand getting everything, we do the following:then we fetch from a reasonable point in the history:
That way we get a shallow, narrow clone of the svn repository.
Then in the future we just need to do:
to update the git svn repo before doing
git rebaseandgit svn dcommitto push back up to the svn repo.我开始写一篇关于如何将 utils/ 作为分支区域公开给 git svn 的回复，然后意识到它根本不是真正的分支；这是一个完全不同的项目。即，该树下的代码与分支、标签和主干树下的代码不共享任何祖先。由于每个人都在检查整个存储库，我想知道合并对您来说如何，但那是另一个故事了。
如果您在这里使用 git-svn，您可能可以像标准存储库一样对待这个存储库。您将拥有整个存储库，但您一次只能使用一个分支（您的提交挂钩似乎正在强制执行这种行为）。至于 utils 目录，您可以考虑为此创建一个单独的 git svn 存储库。毕竟，无论如何，您都不会将更改合并到该区域或从该区域合并，因此除了需要定期更新另一个 WC 之外，您实际上不会丢失任何内容。
祝你好运！
I started to write out a response on how to expose utils/ as a branch area to git svn, and then realized that it isn't really a branch at all; its a different project altogether. I.E., the code under this tree does not share any ancestry with code under the branches, tags, and trunk trees. Since everyone is checking out the whole repository, I wonder how merges are going for you, but that's another story.
If you use git-svn here, you can probably get away with treating this repo like a standard repo. You'll have the whole repository, but you'll only be able to work with one branch at a time (sort of the behavior it seems your commit hooks is enforcing). As for the utils directory, you might consider creating a separate git svn repo just for that. After all, you aren't merging changes into and out of that area anyway, so you really wouldn't lose anything other than needing to update another WC periodically.
Good luck!
最新的答案，但是......
我建议不要使用
-s开关或等效选项对 SVN 存储库根目录运行git svn，除非你真的知道这是什么你想要的。这将导致一个非常“un-git”的最终存储库，其中来自不同分支的代码在您创建的每个 Git 分支中都会重复。 不寒而栗。您想要做的是使用
-s标准布局选项，并让git svn出色地创建正确的分支及其历史记录。关于
utils？它的位置和您对它的描述表明它是一个独立版本的结构。它的变化与每个分支上发生的情况无关，否则它将被存储在每个分支上。要将其引入 Git，您应该首先为此目录创建一个单独的 Git 克隆。然后，您有几个选择：您可以 a) 决定现在将其保存在 Git 中的每个分支，然后将其签入您以后关心的每个分支的 HEAD 中。您可能需要修复并重新标记旧的/重要的标签。或者 b)，只需将其作为独立版本控制的 Git 子模块引入 Git，就像它看起来的那样。然后你可以在每个分支都有它，但集中提交它。您当然需要更新脚本以适应新位置./utils而不是../utils。Latest answer ever, but ...
I would council against running
git svnagainst your SVN repo-root with the-sswitch or equivalents, unless you really know this is what you want. This will result in a very "un-git" eventual repository, where code from your different branches are duplicated within every Git branch you ever create. Shudder.What you want to do is to use the
-sstandard-layout option, and letgit svndo beautiful work creating proper branches and their history.About
utils? It's location and your description of it suggest that it is an independently-versioned structure. Changes in it are independent of what occurs on each branch, otherwise it would be stored per-branch. To bring it into Git, you should firstly create a separate Git clone of just this directory. You then have a couple of choices: you can a) decide that it is now kept per-branch in Git, and just check it into the HEAD of each branch you care about going-forward. You may need to fix and retag old/important tags. Or b), just bring it into Git as an independently-versioned Git sub-module, which is what it appears to be. Then you can have it in every branch, but commit to it centrally. You would of course need to update your scripts to account for the new location./utilsnot../utils.