新闻和更新

SQLAlchemy 源代码仓库已迁移到 Git。

现在 SQLAlchemy 在 Bitbucket 和 Github 上托管了双镜像仓库。

迁移的基本原理包括以下几点：

• Git 更有效地管理仓库大小；虽然 Mercurial 仓库已接近 50M 大小，但 Git 仓库仅为 17M。
• Git 允许轻量级的临时特性分支，可以自由重命名或删除，包括可以修剪已删除分支的变更集。Mercurial 仓库已充满了数十个开发分支，其中一些被废弃，虽然可以通过“关闭”隐藏它们，但永远无法删除。虽然 Mercurial 通过“书签”扩展支持 Git 的部分功能，但用户通常不了解这一点，并继续创建笨拙的分支。在任何情况下，书签都不能解决删除未使用的变更集的问题。Mercurial 中的特性分支通常必须在单独的克隆中进行，以允许在不堵塞主仓库的情况下放弃的可能性。
• 虽然 Mercurial 有各种扩展来模拟 Git 的高级功能，如“rebase”和“collapse”，但出于折叠变更集或操作分支的目的而操作历史记录是 Git 中一流且广泛使用的功能。
• 很大程度上由于 Github 的普及，Git 已经获得了更高的用户群，以至于我们经常有用户要求我们迁移到 Git，以便他们可以提供拉取请求（因为他们不想学习 Mercurial）。

SQLAlchemy 的问题跟踪仓库将继续托管在 Trac 上；虽然 Git 仓库可以在任意数量的地方镜像，但问题跟踪仓库不能（目前！有人可以创建一个分布式问题跟踪器吗？应该很容易做到，虽然让 Github/Bitbucket 使用它，就没那么容易了......），因此 SQLAlchemy 长期的问题讨论历史记录仍然由项目直接维护。

虽然我们倾向于将 Bitbucket 作为“主要”推送仓库的位置，但希望做出贡献的用户应该随意从 Bitbucket 或 Github 提供拉取请求；我们应该能够同时适应两者。

SQLAlchemy Mercurial 仓库 http://hg.sqlalchemy.org/ 将在一段时间内保持运行，直到我们观察到请求已经下降 - 请注意，此仓库未从 Git 镜像，因为仓库需要使用书签而不是分支重新创建，这需要重新创建整个修订历史记录。