同一个 svn 存储库的不同 git-svn 克隆能否期望能够共享更改然后 git svn dcommit? [英] Can different git-svn clones of the same svn repository expect to be able to share changes then git svn dcommit?

问题描述

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

I've read a great deal of "go from svn to git" and other "git-svn workflow" articles on the web, and still I think they often deal with overly simple situations. They are often targeted at guys who just want to use git and hack locally, without using the full power of git, like pull, fetch, merge and the like between multiple developers who would all have cloned the svn repository with git-svn, then still expect to be able to push their changes any time to the (official) svn repository, and get back to working in git and sharing their stuff etc.

每当这些文章承认你不能用纯 git 做所有你会做的事情时，后果和可能的错误永远不会被清楚地解释(或者也许只有我?).甚至 git-svn 手册页也提到了警告，但并没有以广泛的方式提及.

Whenever these articles admit you can't do everything you'd do in pure git, the consequences and possible screw ups are never clearly explained (or maybe it's just me ?). Even the git-svn man page mentions caveats, but not really in an extensive manner.

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

Based on what I've read, I feel there could be problems when git-svn is used in that specific way, which I'll describe below. Can someone tell me if I'm right about this ?

这是想要的"做事方式:

Here is the "wanted" way of doing things:

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 repos 不会共享任何共同的 git 祖先，因此将无法使用您需要共享、合并等的所有 git 命令.是真的吗，我们会在这个工作流程中遇到问题吗?

My question is: am I dreaming? I read some time ago, in a git book I think, that git-svn-clone could create git repositories that are of course a "mirror" of the svn repo, but that git repos created that way by different developers would have different "ids" and commits would have different hashes. So my understanding was that those git repos wouldn't share any common git ancestor, and thus wouldn't be able to use all the git commands you need to share, merge, and so on. Is it true, are we going to face problems with this workflow ?

有时我读到这可以做到，至少使用官方"裸 git 存储库，这将是唯一一个被 git-svn 克隆的存储库，并且所有 git 用户都必须从这个存储库开始.然后你需要有人负责这个中央 git repo，并在将所有内容提交到 svn repo 之前收集 git devs 之间的更改.这将是 git 用户不知道"原始 git repo 来自 svn 的唯一方法，并且会让他们随心所欲地使用所有 git 命令.唯一需要同时精通 git 和 svn(并了解 git-svn 警告)的人将是合并经理"(或他的任何称呼).

Sometimes I read this could be done, using at least an "official" bare git repository, that would be the only one to be git-svn-cloned, and all git users would have to start form this one. Then you need someone who is in charge of this central git repo, and gathers the changes between the git devs, before dcommiting everything to the svn repo. This would be the only way for git users to be "unaware" that the original git repo comes from svn, and would let them use all git commands as they like. The only person who would need to be fluent in both git and svn (and know about git-svn caveats) would be the "merge manager" (or whatever he's called).

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

Am I completely misunderstanding git-svn caveats ? Is there any simpler way of doing this ?

推荐答案

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

The problem is step 4 of course. A dcommit tries to replay your local history to the server. Dcommit pretends that you're a SVN client. Now, if the code you're dcommitting isn't only from you, that's something that is hard to dcommit to SVN.

以下是 guru 对此事的描述:

Here's what the guru writes on the matter:

• 为了简单和与 SVN 的互操作，它是推荐所有 git-svn 用户直接从SVN 服务器(远程 SVN存储库即)，并避免所有git-clone/pull/merge/push 操作在 git 存储库和分支之间要么通过 git svn 检索克隆，也用于推送将变更集返回到远程 SVN存储库.
• git 分支之间交换代码的推荐方法用户是 git format-patch 和 gitam，或者只是 git svn dcommit 到 SVN存储库.
• 由于 git svn dcommit 在内部使用 git svn rebase，因此我们可以使用任何 git 分支git push to before git svn dcommit on他们将需要强制覆盖遥控器上的现有参考存储库.这一般是被认为是不好的做法，请参阅有关详细信息，请参阅 git-push 文档.
• 不建议在我们计划的分支上运行 git merge 或 git pullgit svn dcommit 来自.SVN 没有代表以任何合理或有用的时尚让用户使用 SVN看不到我们所做的任何合并.此外，如果我们 git merge 或 git从 git 分支中拉取SVN 分支的镜像，git svndcommit 可能会犯错分行.
• git clone 不会克隆 refs/remotes/层次结构下的分支或任何 git-svn 元数据或配置.所以创建和管理的存储库使用 git-svn 应该使用 rsync用于克隆，如果要进行克隆
• 我们不应该在我们所做的更改上使用 git commit 的 --amend 选项已经dcommitted.它是认为不好的做法 --amend提交我们已经推送到其他用户的远程存储库，以及dcommit with SVN 与此类似.可以找到有关此的更多信息在修改单个提交和重写历史记录的问题.

• For the sake of simplicity and interoperating with SVN, it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server (the remote SVN repository that is), and avoid all git-clone/pull/merge/push operations between git repositories and branches which are either retrieved via git svn clone and which are also used to push back changesets into the remote SVN repository.
• The recommended method of exchanging code between git branches and users is git format-patch and git am, or just git svn dcommit to the SVN repository.
• Since git svn dcommit uses git svn rebase internally, any git branches we git push to before git svn dcommit on them will require forcing an overwrite of the existing ref on the remote repository. This is generally considered bad practice, see the git-push documentation for details.
• Running git merge or git pull is not recommended on a branch we plan to git svn dcommit from. SVN does not represent merges in any reasonable or useful fashion so users using SVN cannot see any merges we have made. Furthermore, if we git merge or git pull from a git branch that is a mirror of an SVN branch, git svn dcommit may commit to the wrong branch.
• git clone does not clone branches under the refs/remotes/ hierarchy or any git-svn metadata, or config. So repositories created and managed with using git-svn should use rsync for cloning, if cloning is to be done at all.
• We should not use the --amend option of git commit on a change we have already dcommitted. It is considered bad practice to --amend commits we have already pushed to a remote repository for other users, and dcommit with SVN is analogous to that. More information on this can be found at Modifying a single commit and Problems with rewriting history.

这篇关于同一个 svn 存储库的不同 git-svn 克隆能否期望能够共享更改然后 git svn dcommit?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！