9

我在一家 SVN 商店工作，但为了在我的工作中注入一点理智，我使用了 git-svn。越来越多的同事也看到了曙光，现在我们希望在某些情况下完全避开 SVN。目前我们每个人都有自己的 git-svn 存储库，但由于哈希值差异很大，除了普通补丁或通过 SVN 之外，我们无法真正共享任何内容。我们应该如何组织我们的存储库以允许直接共享（通过 git-remote）？

我能想出的唯一方法是一个共享的 git-svn 存储库，我们将其用作 SVN 的网关，但这可能会有点麻烦——如果我们都使用它会更好可以直接从我们自己的 git-svn repos 推送到 SVN。

编辑：不幸的是，我没有对 SVN 服务器的管理员访问权限，所以像subgit这样的解决方案目前用处不大，即使它们很有趣。

4

5 回答 5

7

你可以看看subgit：

SubGit 是一个平滑、无压力的 Svn 到 Git 迁移的工具。在服务器端安装一次，然后根据需要同时使用 Subversion 和 Git。

SubGit 允许设置双向 Subversion 到 Git 复制（可写镜像）。

和：

SubGit 是从 Svn 到 Git 的公司范围内迁移的解决方案，它是：

Much better than git-svn (see comparison);
Requires no changes of the infrastructure that is already in place;
Allows one to use all Git and all Subversion features;
Provides genuine stress-free migration experience.
于 2013-03-07T10:05:40.313 回答
1

如果我们都可以直接从我们自己的 git-svn 存储库推送到 SVN，那就更好了。

不是什么git svn dcommit命令的用途吗？

用于git svn rebase将您的 git clone 重新定位到中央 svn 存储库，然后git svn dcommit将您的本地提交推送到 svn。

我每天都使用 git svn 和GCC git 镜像，它工作得很好。也许那是因为有一个中央只读镜像，它会从 svn 提交中自动更新，所以每个使用 git-svn 的人都会从 git 镜像和相同的提交 ID 中看到相同的历史记录。这允许从只读镜像中获取和合并，然后只是到 git svn rebase 和 git svn dcommit 以将更改推送到 svn repo。然后，这些更改会同步到只读镜像，并由其他所有人以相同的 ID 获取。

于 2013-03-07T10:14:45.207 回答
1

两个不同版本控制系统之间的双向网关比 git 早了很多年。大约 10 年前，我已经在 CVS 和 Arch 之间进行了手工操作。如果您不想购买 subgit，您可以手动维护网关，甚至尝试编写脚本。工作流程很简单：

  • 有两个分支，trunk和master。trunk镜像颠覆，master是加上在 git 中开发的更改
  • 每当颠覆有新变化时：
    1. $ git svn fetch
    2. master$ git merge trunk
  • 每当推送树干时：
    1. trunk$ git merge master
    2. trunk$ git svn dcommit
    3. master$ git merge trunk
  • 您应该原子地执行这两个序列，即一次只执行一个操作。
  • 您可以考虑设置 git-svn 以便它不会使用颠覆修订信息重写提交，以减少 git 中合并提交的数量。
  • 它可以为多个分支完成，但我认为在 git 中合并单独的颠覆分支是行不通的。
于 2013-03-07T10:33:09.247 回答
1

我们处于完全相同的情况。我们所拥有的是（警告，一些伪代码！）：

  • 远程 git repo，脚本化（使用 bash 脚本），不能是 --bare

  • 一个 pre-receive 钩子检查用户名，然后每个收到的 ref 和所有 SVN 映射的分支：（git -> svn）：

    • git checkout -f <branch>
    • git reset HEAD --hard
    • git clean -fdx
    • git merge -n $newrev
    • git svn dcommit

    • 如果失败，则全部还原，

    • 然后，在所有循环之后 - 更新所有 SVN 分支（使用脚本，见下文）

  • 使用最新的 svn 更改（svn -> git）更新 git-svn 分支的 cronjob：

    • git checkout --orphan svn-update <random-branch-name>
    • git svn fetch --all
    • 对于所有 git-svn 分支：git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch>,

  • 用于 git 身份验证的 ssh 密钥

  • 用户管理的 SVN 身份验证（基于 git 用户名，这取决于您的设置）

这样，没有人直接使用 SVN，与纯 git 的唯一区别是您无法更改 git-svn 分支历史记录（因为 SVN 不会让您提交）。

于 2013-03-07T10:39:18.337 回答
1

我处于类似的设置中，这是一个对我和我一起工作的人有用的过程：

  1. git svn clone一个人使用和朋友创建了一个 Git 存储库。

  2. 其他人使用常规 Git 命令克隆第一个 Git 存储库，然后复制svn-remote.{name}第一个存储库的.git/config. 在 中的示例中有执行此操作的说明git help svn。

现在，每个人都有一个git-svn可用于与 Subversion 存储库交互的设置。

更重要的是，每个人都有一个git-svn具有相同分支和提交历史的设置，这意味着他们git svn fetch和朋友创建的提交将是相同的，包括哈希值。此时，除了推送和拉取 Subversion 存储库之外，您还可以在自己之间使用 Git 的所有更高级的分布式功能。

与常规 Git 不同，你需要小心共享配置——如果你的分支结构不同，你的哈希也会不同。有时事情会出错并需要修复（我曾经有两个git svn fetches 同时进行，这以一种微妙的方式破坏了彼此的工作；我不得不回溯我的历史git svn reset并重新获取以保持我的哈希与其他人的匹配）。但这是将这两种工具混合在一起的限制。

于 2013-03-07T16:53:43.193 回答