我应该如何使用Mercurial作为单独的开发人员？

我已经决定将Mercurial用于一个小型的个人项目.

我读过的大部分帮助都是关于在多个用户之间合并更改的.因为我是独唱,所以不会发生.

我应该有多个存储库吗？我的开发计算机已经每晚备份到我的Windows Home Server,因此在其他地方安装第二个存储库仅用于备份目的似乎没什么价值.

我应该每天分支吗？或者只是发布？还是什么时候

一般来说,对于使用Mercurial的单独开发人员,您建议采用哪些做法？

我使用Mercurial开发FsCheck,这是一个托管在codeplex中的单元测试框架.我目前是唯一的开发人员,但偶尔会有人向我发送补丁.

具体来说,我的文件系统中有一个名为"FsCheck"的文件夹.在那里,我有一个存储库,因此有一个名为main的文件夹.通常情况下,我有一些文件夹,我在那里处理特定的功能或错误修复或其他,比如bug-escapingexceptions和feat-statefulchecking以及patch-userFoo.这些是使用hg clone创建的.

当我完成一个功能或错误修复时,我将提交该文件夹中的所有内容并推送到main.主要可能合并.(hg commit,hg push,hg merge).然后我删除文件夹(小心使用hg状态和hg传出我不会丢弃一些有用的东西).

除了在发布之前,我几乎从不在main中工作,在那里我做最后的清理(比如说文档).在发布之前,我在main中标记了版本号(hg tag v0.5.1).

Codeplex使用svn作为sourcecontrol.我只使用它来存储版本,我使用本地检出的SVN工作副本,我使用hg存档复制Mercurial存储库.然后使用svn提交.原始,但它的工作原理(在Windows上使用Mercurial作为SVN'超级客户'在我的opnion中不是非常用户友好)

我还没有必要对以前的版本进行维护,但是我会通过从该版本的修订版本克隆主存储库来做到这一点(这很简单,因为我标记了它),并且在那个单独的存储库中工作.合并回主干线就像将更改推送到主干和合并一样简单.

综上所述:

一个文件夹,用于存储项目名称的所有项目存储库

在该文件夹中有一个主存储库,每个"工作单元"有一个临时存储库,带有工作单元的描述性名称.

这很好,因为您的分支机构以及您正在处理的内容在文件系统中直观可见.

从问题措辞的方式来看,我认为您可能会对版本控制术语产生一些误解.

您应该为每个项目都有一个存储库.您可以将存储库简单地视为文件系统上的文件夹.初始化特定文件夹中的Mercurial存储库时,该文件夹及其任何子文件夹中的每个文件都有资格添加到存储库以进行版本控制.您不一定要添加所有内容,但如果您愿意,可以添加任何内容.

如果您愿意,可以将此本地存储库推送到远程存储库,作为备份形式或与其他人共享代码的方法.但如果它只是一个个人项目,那么这很可能没有必要,特别是因为您已经有了备份解决方案.

分支通常用于保持项目的不同"版本"分开.正如一些人所提到的,这可以作为独立开发人员用于尝试重构代码的方法,或测试针对特定问题的不同方法.如果它没有成功,你不必担心找到回滚的位置,你只需要点燃分支.如果确实有效,则将分支合并回主存储库("主干")并继续.

如果你确实达到了"释放"代码的程度,并且你需要继续维护旧版本,那么你也需要使用分支.例如,假设您发布了1.0版本,并且有些人开始使用它.当他们使用它时,您私下继续努力下一个版本,可能是1.1,在您的主干存储库中添加功能.现在,有人发现了你需要修复的已发布的1.0代码中的错误,但是你不能只在主干中修复它并给它们代码,因为它没有被释放的状态.这是1.0分支派上用场的地方.您可以修复1.0分支中的错误,并将错误修复更改合并到主干中,以便在那里修复错误.然后你可以使用bugfix重新打包1.0并将其发送给你的用户,

除此之外,使用Mercurial solo时通常没有太多花哨的工作.做一些工作,当你完成一项功能时,提交给自己一个"检查点",如果需要你可以在将来回来.你不需要每次保存或类似的东西都提交,只要你觉得你添加了一些有意义的东西就行了.如果你需要回顾它,这将为你提供一个很好的项目历史.

有关更多信息,我强烈建议您花点时间阅读本书:使用Mercurial进行分布式版本控制.您不必阅读高级主题,但至少阅读第1-5章和第8章将为您提供Mercurial和版本控制的一般介绍.

我使用另一个分布式版本控制系统而不是Mercurial,但我怀疑它对此很重要.

在我的个人项目中,我使用了相当大的分支.我通常有一个主开发分支("主干"),它应该始终具有工作版本.我的意思是单元测试和其他自动化测试通过,并且所有代码都通过这些测试进行测试,除了我明确排除在测试覆盖范围之外的小位.这确保了行李箱始终处于良好的形状以便进一步开发.

每当我开始进行更改时,我都会在主干分支上创建一个新分支.这让我可以自由地进行黑客攻击.例如,我可能不担心在这个分支中传递自动化测试.由于它是一个孤立的区域,我可以随心所欲地提交,而且我这样做:microcommits是我最喜欢的分布式版本控制功能.当分支中的工作完成后,我将其合并回主干.

这种工作方式的好处是,如果事实证明我正在进行的改变是一个坏主意,我可以很容易地退出.事实上,没有任何东西可以退出,因为这些变化尚未合并.

有时候我很懒,也没有为我正在开发的新东西创建一个新的分支.当我需要比预期更多的时间来完成工作时,总会发现这是一个错误.当我需要在中间做另一个无关的改变时,它会变得更糟.当我遵循all-work-in-own-branch分支样式时,无关的更改可以在自己的分支中完成,合并到trunk中,然后另一个分支可以合并来自trunk的更改(如果需要).

我每天都使用Mercurial,看到这里,我也帮助了一些支持Mercurial的免费托管服务,ShareSource(我在信用页面上).我一直在使用HG,因为Xen放弃了BitKeeper.

我会建议你,对于个人项目,不惜一切代价避免分支机构.Mercurial对分支的看法与您的预期有很大不同.像Git这样的其他系统使分支(和疯狂的科学家的想法)变得更容易一些.但是,当我需要简单,便宜的分支时,我只使用Git.

我与hg的典型日子:

(See where I left off)
# hg status 

(See what I was doing with foo)
# hg diff -r tip src/foo/foo.c

(Finish one module, commit it)
# hg commit src/foo/foo.c

(Push changes)
# hg push

合并也非常简单,并且从相关存储库中提取特定修订.但是,如果你的独奏,如果得到合并来解决的机会,你可能搞砸了没有更新远程回购.

我已经开始了几个独立的爱好项目,在我发布它们一年后非常受欢迎,我很高兴我使用了HG.它的语法接近颠覆,非常直观,非常便携.

当然,是的,我使用Git和SVN ..但不是用于个人项目.关于我的repo索引的注释(链接发布),我在PHP中重写了hgwebdir,因为我想轻松地修改它的外观并从每个repo中提取RSS.

简而言之,对于个人使用,你会发现它非常友好.提交,标签等很简单..除非你真的需要它们,否则请避开分支.

这是我前一段时间写的一篇教程,描述了如何使用Mercurial管理网站,在设置密钥,hgrc等时可能会发现它很有用.