作为一个单独的开发人员,我应该如何使用Mercurial?

我使用mercurial开发fscheck,这是一个托管在codeplex中的单元测试框架。我目前是唯一的开发者,但偶尔会有人给我发送补丁。

具体来说,我的文件系统中有一个名为“fscheck”的文件夹。在这里,我有一个存储库,因此文件夹,称为main。通常,在我处理特定功能或错误修复或其他问题的文件夹旁边有几个文件夹,比如bug escapingexceptions和feat statefulchecking和patch userfoo。这些都是使用hg clone创建的。

当我完成了一个特性或错误修复后,我提交了该文件夹中的所有内容,并将其推到m a in。可能合并到主文件中。(hg commit、hg push、hg merge)。然后我删除文件夹(小心使用hg status和hg outgoing,我不会丢弃有用的东西)。

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

codeplex使用SVN作为源代码控制。我只将其用于存储版本,为此我使用本地签出的SVN工作副本,并使用hg archive将mercurial存储库复制到该副本。然后使用SVN提交。原始的,但它是有效的(在Windows上使用Mercurial作为SVN“超级客户机”在我的opinion中还不是非常用户友好)

我还不需要对以前的版本进行维护,但是我可以通过从该版本的修订版克隆主存储库(这很容易,因为我标记了它),并在单独的存储库中工作来实现这一点。合并回主主干和将更改推到主主干和合并一样容易。

综上所述:

• 一个文件夹,用于存储项目的所有存储库,其中包含项目名称
• 在该文件夹中,每个“工作单元”有一个主存储库和一个临时存储库,其中包含工作单元的描述性名称。

这很好,因为您的分支和您正在处理的内容在文件系统中直观可见。

从您的问题的表达方式来看,我认为您可能对版本控制术语有一些误解。

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

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

分支通常用于将项目的不同“版本”分隔开。正如一些人所提到的,作为一个独立的开发人员,这对于尝试一种重构代码的方法,或者测试一个特定问题的不同方法非常有用。如果它不起作用,你不必担心要滚回哪里,你只要把树枝烧了。如果它成功了,那么您可以将分支合并回主存储库(“主干”)并继续进行。

如果您确实达到了对代码进行“发布”的程度,并且需要继续维护旧版本,那么您还需要使用分支。例如,假设您发布了版本1.0,并且一些人开始使用它。当他们使用它的时候,您会私下继续为下一个版本(可能是1.1)工作,在您的主干存储库中添加特性。现在,有人在发布的1.0代码中发现了一个你需要修复的bug,但是你不能仅仅在主干中修复它并将代码提供给他们,因为它处于不需要发布的状态。这就是1.0分支的用武之地。您可以修复1.0分支中的bug,并将bug fix更改合并到主干中,以便在那里修复bug。然后,您可以使用bugfix重新打包1.0,并将其分发给用户,而无需考虑如何将主干置于可以向公众发布的状态。

除此之外,使用反复无常的独奏通常没有太多的花哨工作。做一些工作,当您完成一个特性时,提交它给您自己一个“检查点”,如果需要的话,您可以在将来返回到这个检查点。你不需要每次储蓄或类似的事情都承诺,只要你觉得你已经增加了一些有意义的东西就行了。如果你需要回顾一下这个项目,这将给你一个很好的项目历史。

有关更多信息,我强烈建议花些时间阅读本书: Distributed revision control with Mercurial .您不必阅读高级主题,但至少阅读第1-5章和第8章,可以很好地介绍Mercurial和版本控制。

我使用的是另一个分布式版本控制系统,而不是Mercurial,但我怀疑这是否重要。

在我的个人项目中,我使用了相当多的分支。我通常有一个主要的开发分支(“主干”),它应该在任何时候都有一个工作版本。我的意思是,单元测试和其他自动化测试都通过了,所有的代码都通过了这些测试,除了我明确排除在测试覆盖范围之外的小部分。这样可以确保主干始终处于良好的状态,以便进一步开发。

每当我开始处理一个变更时,我都会在主干分支上创建一个新的分支。这给了我自由黑客的自由。例如,我可能不担心通过这个分支的自动化测试。因为它是一个孤立的区域,所以我可以尽可能频繁地提交,而且我确实这样做了:微提交是我最喜欢的分布式版本控制功能。当分支中的工作完成时,我将它合并回主干。

这种工作方式的好处是,如果发现我正在进行的更改是一个坏主意,我可以很容易地退出。事实上,由于更改尚未合并,因此没有任何内容可以退出。

有时我很懒惰,不为我正在开发的新事物创建新的分支。当我需要比我预期的更多的时间来完成这项工作时,总会发现这是一个错误。当我需要做另一个与此无关的改变时,情况会变得更糟。当我按照它自己的分支风格执行所有工作时,不相关的更改可以在它自己的分支中完成,合并到主干中,然后另一个分支可以根据需要从主干中合并更改。

我每天都用汞,看 here ,我也在为数不多的支持Mercurial的免费托管服务中提供帮助, ShareSource (我在学分页上)。从那以后我一直在用汞 Xen 掉在地上的咬人。

我建议你,对于个人项目,不惜一切代价避免使用分支机构。水星航空公司 idea of what a branch is 与你所期望的大不相同。像git这样的其他系统使分支(和疯狂的科学家想法)变得更容易。但是,我只在需要简单、便宜的分支时使用git。

我与汞的典型日子:

(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

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

我已经开始了一些个人爱好项目,这些项目在我发布一年后非常流行,我很高兴我使用了汞。它的语法接近于颠覆,非常直观,非常可移植。

当然,是的,我用的是Git和Svn。但不适用于个人项目。在我的repo索引(发布的链接)上有一个注释,我用php重新编写了hgwebdir,因为我想轻松地修改它的外观,并从每个repo中提取rss。

简而言之,为了个人使用,你会发现它非常友好。提交、标记等很简单。除非你真的需要,否则不要使用树枝。

这是我一段时间前写的一个教程,描述了如何使用 Mercurial to manage a web site ,在设置您的密钥、hgrc等时,您可能会发现它很有趣。

这些通常与您在任何软件项目中所做的工作相同。仅仅拥有或不拥有版本控制是无法讨论的;)

通常,您只需在特性准备就绪时提交即可。因为您有备份,所以不需要每天提交,只需要安全地存储您的工作。

对于分支:在我的单独项目中,我主要使用它来尝试一些想法,例如当我对同一个问题有另一个解决方案时。为此,我也喜欢Git的藏匿命令。

但是我有多个存储库。我有一个主机,可以访问shell。因此,无论我在哪里工作,无论我有什么工作站(在工作时:当我有时间编码时,在家里的桌面上,在父母家时,在lappy上),我都可以与repo同步。

我不知道为什么您需要多个存储库,因为您已经备份了存储库所在的机器。

如果你说你想研究一个特性,不想在你的主代码分支中混乱的话,也许你会为自己进行分支。

但也许你会从 question 我早点摆姿势。

我以前用过cvs,performce,subversion作为我的个人版本控制系统,从大约两周前开始使用mercurial:-)在工作中我们使用MS团队系统…

对我来说,最值得注意的新东西是在不同的机器之间轻松地转换。在工作中,我有一个mercurial repo(使用hg作为对团队系统的超级客户机)。我经常将所有更改推/拉到/从我的笔记本上,这样我在这两台机器上都有完整的历史记录。

在家里,我还从笔记本电脑上推/拉回购协议。

因此,我可以在任何地方工作(家庭办公室使用结实的电脑,在路上使用笔记本电脑或在工作),不用担心我是否会丢失变化。好吧,偶尔我需要合并两个更改,但这很少有伤害…Hg做得很好,imho。

此外,Mercurial的“安装成本”非常低。你读了一个教程,安装它,说“hgint”,然后继续工作。如果某个东西属于您神圣的SVN服务器,那么就不要再谴责它了,放在哪里等等。Mercurial的“摩擦力”比SVN的要低一点。

我认为这取决于您是否维护现有的应用程序 和 同时添加功能(或修复大错误)。

通过这种方式,您可以修复主分支中的错误,同时在其自己的分支中创建新功能。

我在我的应用程序中做到了这一点,但在本地版本的CVS中做到了这一点。另外,如果一个新的开发人员被添加到您的团队中,那么您就可以开始了。

我同意这是与备份不同的问题。

祝你好运,
兰迪斯蒂格鲍尔

SCM是编辑器的一种“智能”撤消缓冲区扩展。你可以回到过去,你可能已经解决了一个问题,但删除了它,因为它已被重构,但你需要再次解决方案,等等。设置一个可视的diff,它将告诉你自上次提交以来所做的更改,或者在过去的两天内,我不断地检查我的代码,如果我不喜欢我的旧解决方案,我会更改它。

分支工作在流上:当您开始朝一个方向发展时,它需要更多的思考,同时您希望在其他方面工作,那么它可以帮助您。

请注意,dvcss将存储库作为单个单元来处理。您可以一个文件一个文件地提交(使用过滤器),但是它们存储对整个存储库的更改。它混淆了cvs(svn)用户的单一文件更改更为规则。

拥有多个克隆的另一个很好的原因(至少如果您有多台计算机)是,您很容易看到是否引入了对代码的依赖性。(也就是说,您的代码是否会在另一台计算机上运行,而这台计算机可能没有您的主工作站拥有的所有开发包)

我建议你 read this link 它概述了实现SCC的各种方法,并选择最适合您需要的方法

像Mercurial、Bazaar和Git这样的DVC已经提供了许多便宜的东西,这样一个军队就可以从扩展的能力中获益。

1. 你可以快速试验 如果您维护 坚持工作纪律 最新分支或非主线分支 同步您的 对DVC有意义地进行了深入研究。

   代码只是毫无顾虑地流动,实际上 可以提供一个人尝试多重的精神自由 解决方案。

2. 有些人为每个人做树枝 他们实现的特性(特别是在Git中) 不管大小。在 Mercurial,这种开发方法 很便宜,所以为什么不使用 能力?所以这可能意味着小小的承诺 更大的承诺一天几次。

   A.如果你采用这种方法,你可能希望 最后将更改推送到非主机回购 工作日的时间间隔 今天完成的工作 和 备份时间 WHS发生 .

   B.我已经安装 科普什 在我的世界里,它起作用了。 完美提供ssh/sftp/scp功能 到~5MB中的Windows框。在那之前我 在虚拟服务器2005上运行Ubuntu Linux到 除其他服务外,提供类似的 功能。 你可以把你的反复无常推向 ssh上的whs框

我总是使用Git或Mercurial,即使是单独使用。

当我想让一些可重用的组件可用于其他项目时,我会分离存储库。 我把配置为当我提交时,它也会自动推送(我是用Tortoise Hg插件推送的),因为有时我忘记了推送,而当地理位置上移动时,我需要那个代码,明白吗?

所以,这是我的小费。