svn - 使用 git-svn 和共享的 subversion 主线会损失多少 git 的功能？

Question

我正在评估让我们的团队远离 CVS 的各种选择。我们在另一个网站上有另一个大型团队使用 Subversion，我们的一些开发人员使用 Subversion 服务器。因此，Subversion 是我们团队的不二之选。然而:

1. 涉及 Subversion 的操作服务器可能很慢(虽然我们关系很好站点之间)。
2. 我们中的许多人都卖掉了关于分布式版本的想法控制，并使用 Mercurial 或 git广泛(然后 merge 并提交到 CVS 并从中获取更改

git-svn看起来 interesting但我想知道的是，由于在 Subversion 中拥有少量集中式分支，DVCS(如 git)的功能有多少会丢失。特别是，我仍然希望能够保留我们使用 Mercurial 的那种工作流程，例如:

1. 我们能否 pull 其他团队成员的存储库并 merge ，从而在功能分支进入我们在 Subversion 上的稳定主干之前在功能分支上进行协作？
2. 我们是否可以期望 git 的大量花招普遍有效，或者我们是否需要小心避免混淆 git-svn？
3. 我们能否使用 git 来加快从 Subversion 的 checkout 速度，方法是将它 pull 过来自其他站点的连接一次，然后将其 pull 入单独的存储库一次。
4. 如果有人提交 Subversion，我们能否安排其他 git 用户通过 git-svn 仍然看到完整的开发历史？
5. 我们能否基本上避免在 Subversion 服务器上等待交互式操作，尽管它有半个世界的延迟？

我们中的许多人都习惯了一个主要的相当稳定的共享分支的想法，每个人都可以推送到一个简单的线性历史，因此他们定期 merge 到 tip。我不清楚如何使用 git(或 Mercurial 或 Bazaar)很好地支持此工作流程。

Answer 1

你确实失去了很多，感觉有点二等，但你确实获得了所有美妙的分支。

我通过使用 git 来处理托管在 subversion 中的项目来学习 git。 git 允许我进行所有本地开发并在项目上取得相当大的进展，同时仍然跟踪主流分支，甚至与他人分享我的工作。

最后，由于在进行颠覆时丢失了所有信息，我们最终将整个项目推送到 git。

你失去了什么:

1. merge 跟踪 -- 有点。
2. 正确记录更改的作者。

我说“有点”WRT #1 因为如果你把一棵树放在一起，它会跟踪你用 git 做的 merge 和东西并应用于颠覆，但是一旦你尝试克隆那个 repo，或者其他人做了一个 git-svn 克隆，你失去了它并且 merge 再次变得非常痛苦。

作者身份对我来说很重要，因为我发现确保人们因其所做的工作而获得荣誉非常重要。