透明的 git-svn 网关

Question

目前我们有一个 Subversion 存储库，其布局如下：

• /截断
  • /group1
    • /项目1
    • /项目2
  • 第 2 组
    • /项目3
    • /ETC..
• /标签
  • /group1
    • /项目1
    • /项目2
  • 第 2 组
    • /项目3
    • /ETC..
• /分支
  • /任何临时的事情

我认为这是一个相当糟糕的布局，但目前很难完全改变它。

我个人不喜欢 subversion，主要是因为检查历史记录需要很长时间，而且分支和合并很麻烦等等，所以我真的想使用 git。

遗憾的是，我们不能直接切换到 git，因为有些人的心理承受能力可能太强，所以我正在研究 git-svn，看看是否可以实际使用它来解决这个问题。

遗憾的是，这直接导致了一个糟糕的局面，因为我想将每个项目分解为一个 git 仓库，而我不想在我工作的每台计算机上重新创建 git-svn 检出。所以我认为也许有可能创建某种透明的 git ←→ svn 代理/网关，这样对该仓库的推送就会“提交”到 svn 仓库，而对 svn 仓库的提交会更新 git 仓库。

Google 并不是我的朋友，只发现了使用 git-svn 的通用用法帮助，所以我问你是否有一些好的想法来实现这一点。

Answer 1

对于透明的 Git/Svn 网关，您可以使用子Git，它非常符合您的要求，只是目前它只支持简单的单项目（/trunk、/branches、/tags）或多项目（/project/trunk，...）布局。

Answer 2

如果您无法控制或不想弄乱 Subversion 服务器，则无法使用 SubGit。在这种情况下，您可以为每个主干设置一个自动同步的 git 存储库。我们的团队以这种方式工作 - 我们有一个 git-Subversion 桥，它可以同步我们团队 git 存储库和公司 Subversion 存储库中的项目主干之间的更改，以便我们的 git 使用情况对其他 Subversion 用户透明。

该设置的详细描述请见https://github.com/mrts/git-svn-bridge。

我们在生产中使用这个设置已经一年多了。

我认为该设置的最大缺点是，在合并到主干时，git 分支将被压缩为一个提交。对我们来说，这没有问题 - 我们使用短期任务分支，并将它们视为轻量级、短暂的“工作单元”，可以以单个块的形式进入主线 - 并且分支历史记录保留在 git 中。

Answer 3

你基本上有两个选择：

1. 允许客户端的 git-svn 解决问题。您的初始签出将需要一段时间，但它可以为您提供与本机 svn 签出相同的所有功能（包括通过 和 推送和拉取git svn dcommit）git svn [fetch|rebase]，如果您使用 克隆它--stdlayout，您将获得完整的分支和标记支持。（我在公司这样做——我是两名使用 git 和 svn 服务器的员工之一，我没有遇到任何问题。）

2. 使用 git-svn 将存储库克隆到另一台服务器（甚至是同一台服务器），然后只需从该存储库开始托管 git 即可。然后您就拥有了一个原生 git 存储库，其中包含之前的所有 svn 数据。

Answer 4

如果您不想在每台计算机上“git svn clone”，您可以：

1. “git svn clone”一次，然后将存储库分发到每台计算机。[最简单，但并非您所需要的]。
2. 按照 Mickey 在“2”点中说的做（“用 git-svn 克隆存储库，然后从该存储库开始托管 git”）并运行两个钩子：一个将提交从 git 带到 svn（如果没有冲突），另一个将提交从 svn 带到 git（如果没有冲突)。这可能很复杂（尤其是如果考虑分支/标签），并且当 SVN 和 Git 都编写时，两个存储库将出现分歧。这可以作为过渡方案（在进入点“3”之前），但不利于解决它。
3. 执行一次性“git svn clone”，删除 SVN 存储库，仅托管 Git。[简单，但不是您需要的]。