同一个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-svn手册页都提到了警告，但并不是真正的广泛。

根据我读过的内容，我觉得git- svn以特定的方式使用，我将在下面介绍。有人可以告诉我我是否正确吗？

这是想要的做事方式：

开发人员git-svn-clone是svn仓库。他开始在本地破解东西

开发者B git-svn-clone与svn相同。他开始自己破解东西。

在做了一段时间之后，可能会添加开发人员C / D / ...，并让其他开发人员执行标准svn提交原始的回购，git用户会想要分享他们的代码，并做各种git魔术。

任何一个git用户都希望能够将现在合并的更改推送到svn（dcommit？）

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

有时候我读过这个可以做到，至少使用一个官方裸git仓库，是唯一一个被git-svn克隆的人，所有的git用户都必须从这个开始。然后你需要一个负责这个中心git回购的人，并收集git开发者之间的变化，然后把所有的东西交给svn回购。这将是git用户不知道原始git repo来自svn并让他们使用所有git命令的唯一方法。唯一需要在git和svn上流利的人（并且知道git-svn警告）将是合并经理（或者他所称的任何人）。

我完全误解git-svn警告？有没有更简单的方法来解决这个问题？

解决方案

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

以下是古鲁在这件事上写道：

• 为简单起见并与SVN互操作，
  建议所有git-svn用户
  直接从
  克隆，获取并提交dcommit，SVN服务器（远程SVN
  存储库），并避免所有
  git -clone / pull / merge / push操作git仓库和分支
  之间的
  通过git svn
  克隆获取，也用于将
  返回的变更集推送到远程SVN
  仓库。


• 在git分支
  和用户之间交换代码的推荐方法是git format-patch和git
  am，或者只是git svn dcommit到SVN
  仓库。
  
• 因为git svn dcommit在内部使用git svn rebase，所以任何git分支我们
  git push到git svn dcommit on
  m将需要强制覆盖远程
  存储库中现有ref的
  。这通常是
  被认为是不好的做法，请参阅
  git-push文档以获得详细信息。


• 我们计划在分支上不推荐使用git merge或git pull
  git svn dcommit from。 SVN不
  表示合并或
  有用时尚的合并，因此使用SVN
  的用户无法看到我们所做的任何合并。
  此外，如果我们将git merge或git
  从一个SVN分支的
  镜像的git分支拉出来，git svn
  dcommit可能会提交到错误的
  分支。


• git clone不会在refs / remotes / hierarchy或
  任何git-svn元数据或配置下克隆分支。因此，使用git-svn创建和管理
  的
  仓库应该使用 rsync
  进行克隆，如果克隆完成
  。


• 我们不应该使用git commit的--amend选项我们
  的变化已经被提交。
  被认为是不好的做法 - 我们已经将
  提交到其他用户的
  远程存储库中，
  dcommit与SVN类似。
  有关这方面的更多信息可以在
  修改单个提交和
  重写历史记录的问题。

  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.

  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.

  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. We have a project in a svn repository
  2. Developer A git-svn-clone's the svn repo. He begins to hack things locally
  3. Developer B git-svn-clone's the same svn repo. He begins to hack things on his own.
  4. After doing that for some time, possibly adding devs C/D/..., and having other developers who do "standard" svn commits to the original repo, the git users would want to share their code and do all kinds of git magic.
  5. Any one of those git users would like to be able to push the now merged changes to svn (dcommit?)

  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 ?

  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).

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

  解决方案

  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.

  Here's what the guru writes on the matter:

  • 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屋！