同一 svn 存储库的不同 git-svn 克隆是否可以期望能够共享更改，然后 git svn dcommit ？

StackOverflow https://stackoverflow.com/questions/1880405

  •  18-09-2019
  •  | 
  •  

题

我在网上阅读了大量的“从 svn 到 git”和其他“git-svn 工作流程”文章，但我仍然认为它们经常处理过于简单的情况。它们通常针对那些只想在本地使用 git 和 hack 的人，而不使用 git 的全部功能，例如在多个开发人员之间进行拉、取、合并等操作，这些开发人员都使用 git-svn 克隆了 svn 存储库，然后仍然希望能够随时将他们的更改推送到（官方）svn 存储库，然后继续在 git 中工作并分享他们的东西等。

每当这些文章承认你无法完成在纯 git 中所做的所有事情时，其后果和可能出现的错误永远不会被清楚地解释（或者也许只是我？）。甚至 git-svn 手册页也提到了警告，但并不是很广泛。

根据我所读到的内容，我觉得以特定方式使用 git-svn 时可能会出现问题，我将在下面描述。有人可以告诉我我的说法是否正确吗？

这是“想要的”做事方式：

  1. 我们在 svn 存储库中有一个项目
  2. 开发人员 git-svn-clone 是 svn 存储库。他开始在本地进行黑客攻击
  3. 开发人员 B git-svn-clone 具有相同的 svn 存储库。他开始自己破解一些东西。
  4. 这样做一段时间后，可能会添加开发人员 C/D/...，并且让其他执行“标准”svn 的开发人员提交到原始存储库，git 用户会希望共享他们的代码并执行各种 git 魔法。
  5. 这些 git 用户中的任何一个都希望能够将现在合并的更改推送到 svn （dcommit？）

我的问题是：我在做梦吗？我前段时间在一本 git 书中读到，我认为 git-svn-clone 可以创建 git 存储库，这些存储库当然是 svn 存储库的“镜像”，但不同开发人员以这种方式创建的 git 存储库会有不同的“ ids”和提交将具有不同的哈希值。所以我的理解是，这些 git 存储库不会共享任何共同的 git 祖先，因此无法使用您需要共享、合并等的所有 git 命令。这是真的吗？我们会面临这个工作流程的问题吗？

有时我读到这可以做到，至少使用一个“官方”裸 git 存储库，这将是唯一一个被 git-svn 克隆的存储库，所有 git 用户都必须从这个存储库开始。然后，您需要有人负责这个中央 git 存储库，并在将所有内容提交到 svn 存储库之前收集 git 开发人员之间的更改。这将是 git 用户“不知道”原始 git 存储库来自 svn 的唯一方法，并让他们可以随心所欲地使用所有 git 命令。唯一需要精通 git 和 svn （并且了解 git-svn 注意事项）的人是“合并经理”（或者无论他被称为什么）。

我是否完全误解了 git-svn 警告？有没有更简单的方法来做到这一点？

有帮助吗？

解决方案

问题当然是第4步。dcommit 尝试将本地历史记录重播到服务器。Dcommit 假装您是 SVN 客户端。现在，如果您提交的代码不仅仅来自您，那么就很难提交到 SVN。

这是什么 大师 关于此事写道：

  • 为了简单起见并与SVN进行互操作，建议直接从SVN服务器（远程SVN存储库）直接克隆，获取和DCommit，并避免使用所有Git-clone/pull/pull/merge/pusth GIT存储库和分支之间的操作要么通过GIT SVN克隆检索，而且还用于将更改推入远程SVN存储库。
  • 在GIT分支和用户之间交换代码的推荐方法是Git格式 - 绘图和GIT AM，或者只是GIT SVN DCOMMIT到SVN存储库。
  • 由于GIT SVN DCommit使用Git SVN内部使用GIT SVN REBASE，因此我们将GIT推送到GIT SVN DCommit上的任何GIT分支都将需要迫使在远程存储库上覆盖现有的Ref。这通常被认为是不良习惯，有关详细信息，请参见Git-Push文档。
  • 我们计划从我们计划的git svn dcommit上进行运行的git合并或git拉。SVN不能以任何合理或有用的方式代表合并，因此使用SVN的用户看不到我们已经进行的任何合并。此外，如果我们从git分支中合并或git将是SVN分支的镜像，则GIT SVN DCOMMIT可能会归结为错误的分支。
  • git克隆不会在参考/遥控器/层次结构或任何git-svn元数据或配置下克隆分支。因此，使用git-svn创建和管理的存储库应使用 同步为了克隆，如果要进行克隆。
  • 我们不应在已经签署的更改上使用 - 安装选项。我们已经将我们推向其他用户的远程存储库被认为是不良的做法，而使用SVN的DCommit类似。有关此信息的更多信息，可以在修改单个提交和 重写历史的问题.

其他提示

我最近对此进行了很多尝试，并且认为我设法想出了一个有点工作的设置。是的，这是一个严格的 rebase-only 制度，是的，它很复杂，但你确实可以使用 Git 在本地工作（速度、历史记录、存储、索引等）。

我认为，当你与团队中的其他 Git 用户协作时，你可以在幕后使用分支，但我个人还没有对此进行太多实验。只要在提交之前将日志线性化，它就应该可以工作。

这是简短的版本（重复了很多已经说过的内容）：

  1. 将 Subversion 存储库克隆到中央服务器上的“获取”存储库中
  2. 在同一服务器上初始化一个“裸”存储库
  3. 从 fecting 仓库推送到裸仓库
  4. 让开发人员克隆裸存储库，然后
    1. git svn init svnurl 配置 git-svn 远程，以及
    2. git update-ref refs/remotes/git-svn refs/remotes/origin/master 所以 git-svn 有一个指向修订版本的指针
  5. 自动（提交挂钩）“获取”存储库 svn rebase，并推送到裸存储库
  6. 开发人员从裸仓库中提取 git pull --rebase
  7. 开发者运行 git svn dcommit 首先必须重复 update-ref 如果有来自 SVN 的新修订，请参见上述内容。

有一个 此页面上的工作流程插图 （我需要更多声誉点才能内联图像）。更新：开始了：

我以前所做的，是创建一个初始的 git svn 克隆，然后使用 git 在开发人员之间共享 .git，因此我们拥有完全相同的引用。

它似乎工作正常，因为我们能够在 git 用户之间使用“特定的 git 功能”，只要我们保持在线性树中（即变基而不是合并）。

一旦你涉及“分布式”问题，你最好在开发人员之间克隆一个裸露的 git 存储库。
关于公共 SVN 存储库的导出-导入阶段，供其他人使用，脚本
git2svn 和 svn2git 可以帮助封装魔法。

在 Git 和 SVN 存储库中工作时的其他注意事项可以在问题中找到 “git 的工作流程和帮助、2 个 svn 项目和一个“工作副本””

有一个工具可以解决共享与 Subversion 存储库同步的 Git 存储库的问题。

子Git 是一个Git-SVN双向服务器端镜像。

可以将 SubGit 安装到 Subversion 存储库中，并让 Git 存储库自动与 SVN 同步：

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit 将预提交和后提交挂钩安装到 Subversion 存储库中，将预接收和后接收挂钩安装到 Git 存储库中。因此，它会立即翻译来自 SVN 和 Git 端的传入修改。安装 SubGit 后，开发人员可以使用任何 Git 客户端来克隆和使用 Git 存储库。

SubGit 不依赖于 git-svn，它使用我们团队开发的自己的翻译引擎。有关这方面的更多详细信息，您可以在以下位置找到 SubGit 对比git-svn 比较。提供了有关 SubGit 的一般文档 这里.

SubGit 1.0 版本需要本地访问 Subversion 存储库，即SVN 和 Git 存储库必须驻留在同一主机上。但在 2.0 版本中，我们将引入 Git 代理模式，此时 Subversion 和 Git 存储库可以位于任何地方，并且只有 Git 存储库安装了 SubGit，即Subversion 存储库保持不变。

SubGit 是一个商业产品。对于开源学术项目以及最多 10 名提交者的项目来说，它是免费的。

免责声明：我是 SubGit 开发人员之一。

我发现 这篇博文 这建议保留一个单独的分支来与 Subversion 存储库同步，这样仍然可以在 master 分支中进行推/拉操作。

我认为 git-svn 的问题之一是它将 git-svn-id 存储在提交注释中；因为这会重写该提交，它会更改它的 SHA1，因此您无法将其推送到人们将共享它的任何地方。

我实际上更喜欢 bzr-svn，因为它使用 SVN 修订属性功能将 bzr revid 存储在远程 SVN 修订中，这意味着没有本地修订重写。它还具有所需的属性，即同一 SVN 分支的两次独立拉取将产生相同且可互操作的 bzr 分支。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top