ide - Mercurial 做法 : use with IDEs and scalability

Question

我不是 SCM 工具的经验丰富的用户，尽管我确信它们的用处，当然。
我在以前的工作中使用了一些不起眼的商业工具，在当前的工作中使用了 Perforce，并在我的小型个人项目中使用了 TortoiseSVN，但我不喜欢到处都有很多 .svn 文件夹，进行搜索、备份等等难的。
然后我发现了分布式 SCM 的兴趣，我选择了明显更简单(比 git)的 Mercurial 方式，仍然是为了我个人的个人需求。我正在学习如何正确使用它，阅读了 wiki 的一部分，并且正在阅读这本优秀的 PDF 书籍。

我经常看到重复，例如在 Mercurial working practices ，“不要犹豫，在本地使用多棵树。Mercurial 使这变得快速而轻量。”和“为您处理的每个功能，创建一棵新树。”。
这些是有趣且明智的建议，但它们有点伤害了我使用集中式 SCM 的小习惯，在那里我们有一个“神圣”的中央存储库，其中分支经过精心规划(并由管理员处理)，变更列表必须由(高级)同行检查，并且不得破坏构建等 :-) 开始在新分支上工作需要相当长的时间......

因此，鉴于上述情况，我有两个问题:

在 IDE 等环境中进行大量克隆有多实用？如果项目有配置/设置文件、makefile 或 Ant 脚本或 shell 脚本或其他需要路径更新的东西怎么办？ (是的，可能是个坏主意...)例如，在 Eclipse 中，如果我想编译并运行一个克隆，我必须再做一个项目，调整 Java 构建路径、运行/调试目标等等.除非 Eclipse 插件可以简化该任务。我想念这里的一些设施吗？

那怎么缩放？我读过 Hg 对于大型代码库是可以的，但我很困惑。在我的工作中，我们有一个大约 200 万行的 Java 应用程序(嗯，几个围绕一个大型通用内核)，仅代码就占 110MB。在我的旧(2004)Windows 工作站上进行干净编译需要大约 15 分钟才能生成 50MB 的类文件!我没有看到自己克隆整个项目来更改 3 个文件。那么这里的做法是什么？

我还没有在我的阅读中看到这些问题，所以我希望这将成为一个有用的线程。

Answer 1

你提出了一些好点!

• How practical is it to do lot of clones, in the context of IDEs and such?

没错，当 IDE 和其他工具依赖于绝对路径时，可能很难管理许多克隆。部分问题可以通过始终在配置文件中使用相对路径来解决——确保源代码 check out 可以从任何位置编译本身就是一个很好的目标，无论您使用什么版本控制系统:-)

但是当您不能或不想打扰多个克隆时，请注意 a single clone can cope with multiple branches . “hgbook”强调了许多克隆，因为这是一种概念上简单且非常安全的工作方式。当您获得更多经验时，您会发现您可以在单个存储库中使用多个头(也许通过使用 bookmarks 命名它们)来做同样的事情。

• How do that scale?

克隆 110 MB 的存储库应该很快:这取决于将 110 MB 写入磁盘需要多长时间。在 recent message to the Mercurial mailinglist据报道，克隆 6.3 GB 需要 4 分钟——将其缩小到 110 MB 大约需要 4 秒。这应该足够快，你的茶仍然是温暖的 :-) 诀窍的一部分是历史数据只是硬链接(hard link)(是的，也在 Windows 上)，所以只需写出工作中的文件复制。