Question

我不是SCM工具的实验用户，当然，尽管我确信它们有用。我在以前的工作中使用了一些模糊的商业工具，在当前的工作中使用了Perforce，并且在我的小个人项目中使用了TortoiseSVN，但我不喜欢在这个地方有很多.svn文件夹，进行搜索，备份等等难。然后我发现了分布式SCM的兴趣，我选择了显然更简单（比git）的Mercurial方式，仍然是为了我个人的个人需求。我正在学习正确使用它，阅读了部分维基并处于优秀PDF书的中间。

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

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

在IDE等环境下，做很多克隆有多实用？如果项目有配置/设置文件，makefile或Ant脚本或shell脚本或其他什么需要路径更新，该怎么办？（是的，可能是一个坏主意...）例如，在Eclipse中，如果我想编译并运行一个克隆，我必须做另一个项目，调整Java构建路径，运行/调试目标，等等。除非Eclipse插件可以轻松完成该任务。我在这里错过了一些设施吗？
这个规模如何？我已经阅读过Hg可以用于大型代码库，但我很困惑。在我的工作中，我们有一个Java应用程序（好吧，几个围绕一个很常见的内核），大约有两百万行，单独为代码加权大约110MB。在旧的（2004）Windows工作站上进行干净的编译需要大约15分钟来生成50MB的类文件！我没有看到自己克隆整个项目来更改3个文件。那么这里的做法是什么？

我还没有在阅读材料中看到这些问题，所以我希望这会成为一个有用的主题。

Answer 1

你提出了一些好处！

在IDE等环境中做很多克隆有多实用？

当IDE和其他工具依赖于绝对路径时，很难管理很多克隆。部分原因可以通过始终在配置文件中使用相对路径来解决 - 无论您使用何种版本控制系统，确保源检出可以从任何位置编译都是一个很好的目标： - ）

但是当你不能或不想打扰几个克隆时，请注意a single clone can cope with multiple branches。 “hgbook”强调了许多克隆，因为这是一种概念上简单且非常安全的工作方式。当您获得更多经验时，您将看到可以在单个存储库中使用多个头（可能通过使用bookmarks命名）来执行相同的操作。

这个规模如何？

克隆110 MB存储库应该非常快：它取决于将110 MB写入磁盘所需的时间。在recent message to the Mercurial mailinglist中，据报道克隆6.3 GB需要4分钟 - 缩小到110 MB，大约需要4秒。这应该足够快，你的茶仍然温暖:-)部分原因是历史数据只是硬链接（是的，也在Windows上），因此只需要在工作中写出文件副本。

Answer 2

PhiLo：我是新手，但mercurial也有“内部分支”，您可以在单个存储库中使用而不是克隆它。

而不是

hg clone toto toto-bug-434

你可以做到

cd toto
hg branch bug-434
hg update bug-434
...
hg commit
hg update default

创建分支并来回切换。当您切换分支时，不受转速控制的构建文件将不会消失，其中一些文件将在修改基础源时过时。您的IDE将重建所需的内容而不再重建。它的工作原理很像CVS或颠覆。

除了“工作”存储库之外，您还应该拥有干净的“传入”和“传出”存储库。只是你的“工作”可以用于多种目的。

那就是说，你应该在尝试任何错综复杂的事情之前克隆你的工作回购。如果出现任何问题，你可以将克隆扔掉并重新开始。

Answer 3

问题1：

PIDA IDE具有非常好的Mercurial集成。我们还使用Mercurial进行开发。就个人而言，我在一些项目中有大约15个并发克隆，并且IDE可以很好地应对。我们没有调整构建脚本等的麻烦，我们可以“克隆并去”。

很容易在很多情况下克隆到错误编号，如：

hg clone http://pida.co.uk/hg pida-345

对于bug＃345，我准备修复。

如果您必须根据应用程序的实际结帐目录调整构建脚本，我可能会认为您的构建脚本应该使用某种项目相对路径，而不是硬编码路径。

Mercurial实践：与IDE一起使用和可扩展性

3 个答案: