我应该如何使用Mercurial作为一个独立的开发者?

我已经决定,我想用Mercurial来做一个小型的个人项目。

我读过的大部分帮助都是关于合并多个用户之间的更改。 由于我是独奏,这不会发生。

我应该有多个存储库? 我的开发计算机已经备份到我的Windows家庭服务器每晚,所以似乎没有其他地方的第二个存储库仅用于备份的目的。

我应该每天分手吗? 或者只是在发布? 或者当?

一般来说,您推荐使用Mercurial的独立开发人员使用哪些实践?

我使用Mercurial来开发FsCheck,这是一个在codeplex中托pipe的unit testing框架。 我目前是唯一的开发者,但偶尔会有人给我发补丁。

具体来说,我在我的文件系统中有一个名为“FsCheck”的文件夹。 在那里,我有一个存储库,因此文件夹,称为主。 通常情况下,我有几个文件夹旁边,我工作的具体function或错误修复或其他什么,说bug-escapingexceptions和feat-statefulchecking和patch-userFoo。 这些是使用hg克隆创build的。

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

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

Codeplex使用svn作为sourcecontrol。 我只使用它来存储版本,我使用本地签出的SVN工作副本,我使用hg归档复制Mercurial存储库。 然后提交使用svn。 原始的,但它的作品(使用Mercurial作为SVN的“超级客户端”在Windows上是不是非常人性化,但在我的opnion)

我还没有对之前的版本进行维护,但是我会通过克隆该版本的修订版本(这很容易,因为我标记了它),并在该单独的版本库中工作。 合并回主干只要将更改推送到主合并即可。

综上所述:

  • 一个文件夹来存储您的项目的所有资料库,以及您的项目的名称
  • 在该文件夹中有一个主要的存储库,每个“工作单元”有一个临时存储库,其中有一个工作单元的描述性名称。

这很好,因为你的分支和你正在做的是在文件系统中直观的可见。

从你的问题的措辞来看,我认为你可能会有一些与版本控制术语相关的误解。

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

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

分支通常用于保持项目的不同“版本”分离。 正如一些人所提到的,这可以作为独奏开发者尝试一种重构代码的方法,或者针对特定问题testing不同的方法。 如果不能解决问题,你不必担心如何回滚到哪里,只需要分支。 如果确实起作用,则将分支合并回主存储库(“主干”)并继续进行。

如果你确实到了代码“发布”的地步,而且你需要保持旧版本,那么你也需要使用分支。 例如,假设您发布1.0版本,并且有些人开始使用它。 当他们使用它时,你私下继续朝着下一个版本(也许是1.1)努力,在你的中继库中增加一些function。 现在,有人发现了1.0版本中的一个bug,你需要修正,但是你不能把它修改成trunk,并给它们代码,因为它没有被释放的状态。 这是1.0分支派上用场的地方。 您可以修复1.0分支中的错误,并将错误修正更改合并到主干中,以便错误也在那里修复。 然后,你可以重新打包补丁1.0的错误修复,并将其发送给你的用户,而不必弄清楚如何将树干进入一个状态,它可以发布给公众。

除此之外,使用Mercurial solo的过程中通常不会有很多花哨的工作。 做一些工作,当你完成一个function时,把它提交给自己一个“检查点”,如果需要,你可以在将来回来。 你不需要每次保存或任何类似的东西,只要你觉得你添加了一些有意义的东西就可以了。 这将会给你一个很好的项目历史,如果你需要回顾一下。

有关更多信息,我强烈build议花些时间阅读本书: 使用Mercurial进行分布式版本控制 。 您不必阅读高级主题,但至less阅读第1-5章和第8章将会对Mercurial和版本控制有一个很好的介绍。

我每天都会使用Mercurial, 在这里看到,我也帮助支持Mercurial, ShareSource的less数免费托pipe服务之一 (我在信用页面上)。 自从Xen放弃BitKeeper以来,我一直在使用HG。

我会build议你,个人项目,不惜一切代价避免分支机构。 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 

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

一年后,我开始了一些个人爱好项目,这些项目在我发布之后一年十分stream行,我很高兴我使用了HG。 它的语法接近于颠覆,它非常直观,非常便于携带。

当然,是的,我使用Git和SVN ..但不是用于个人项目。 关于我的回购索引(发布的链接)的一个说明,我重新编写了PHP的hgwebdir,因为我想轻松修改它的外观,并从每个回购拉动RSS。

总之,对于个人使用,你会发现它非常友好。 提交,标签等很简单..避免分支,除非你真的需要它们。

这是我前段时间写的一个教程,描述了如何使用Mercurial来pipe理一个网站 ,当你设置你的密钥hgrc等时,你可能会感兴趣。

我使用另一个分布式版本控制系统比Mercurial,但我怀疑这个问题。

在我的独奏项目中,我使用相当重的分支。 我通常有一个主要的开发分支(“主干”),应该始终有一个工作版本。 我的意思是unit testing和其他自动化testing通过,并且所有的代码都是通过这些testing来testing的,除了我已经明确排除在testing覆盖之外的那些小的代码。 这确保了后备箱总是处于进一步发展的良好状态。

每当我开始工作一个改变,我创build一个新的分支树干分支。 这给了我自由的自由。 例如,我可能不担心在这个分支中传递的自动化testing。 由于它是一个孤立的区域,所以我可以像我喜欢的那样经常下载,而且我也这么做:microcommits是我最喜欢的一个分布式版本控制function。 当分支中的工作完成后,我将它合并回主干。

这种工作方式的好处是,如果事实certificate,我正在做的改变是一个坏主意,我可以轻易退出。 事实上,没有什么可退缩的,因为这些变化并没有被合并。

有时候我很懒,也不会为我正在开发的新东西创build一个新的分支。 不可避免的是,这是一个错误,当我需要更多的时间比我预期完成的工作。 当我需要在这个中间做另一个无关的变化的时候,情况会变得更糟。 当我按照自己的分支风格工作时,无关的变化可以在自己的分支中完成,合并到主干中,如果需要的话,另一个分支可以从主干中合并变化。

这些通常和你在任何软件项目上工作的一样。 简单的有或没有版本控制是超出任何讨论;)

通常你只需要在你的function准备好的时候提交。 既然你有一个备份,你不需要每天提交只是为了安全地存储你的工作。

对于分支:在我的独奏项目中,我主要用于尝试创意,例如。 当我有相同的问题的另一个解决scheme。 为此,我也喜欢Git的隐藏命令。

不过,我有多个存储库。 我有一个托pipe的shell访问,我推。 所以无论我在哪里工作,无论我在哪个工作站(在工作中:当我有时间编码,在家里桌面时,在家里时,在lappy上),我都可以与该回购同步。

我不知道为什么你会想要多个存储库,因为你已经备份了你的机器的存储库将驻留。

也许你会为自己分支,如果说你想调查一个function,而不想在你的主代码分支争夺。

但也许你会从我之前提出的问题中提取出一些东西。

我曾经使用CVS,Perforce,Subversion作为我的个人版本控制系统,并在两周前进入了Mercurial :-)在工作中,我们使用MS Team System …

对我来说,最值得注意的新事物是在不同的机器之间轻松传输。 在工作中,我有一个mercurial repo(使用hg作为超级客户端反对Team System)的东西。 我经常推/拉我的笔记本电脑的所有变化,所以我在这两台机器上都有完整的历史logging。

在家里我也推/拉笔记本电脑的回购。

因此,无论身在何处,我都能工作(家庭办公室使用强健的电脑,在使用笔记本电脑的路上或在工作中),而不用担心是否会失去改变。 好的,偶尔我需要合并两个更改,但很less伤害…汞很好地恕我直言。

另外,mercurial的“设置成本”也相当低。 你阅读一个教程,安装它,说“hg init”并继续工作。 如果某件东西属于你神圣的SVN服务器,放在哪里等等,那么就不要再做了。 Mercurial的“摩擦”比SVN略低。

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

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

我完全用我的应用程序,但是与本地版本的CVS。 另外,如果新开发者被添加到你的团队中,你将全部离开。

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

祝你好运,
兰迪Stegbauer

SCM是编辑器的一种“智能”撤销缓冲区扩展。 你可以回去的时间,你可能已经解决了一个问题,但删除它,因为它已被重构,但你将需要再次解决scheme,等等。设置一个视觉比较,它会告诉你自从上一次你已经改变在过去的两天里,我不断地检查我的代码,如果我不喜欢我以前的解决scheme,就更改它。

分支在stream中工作:当你开始向一个方向前进时,但是需要更多的思考,同时你想要做其他事情,那么它可以提供帮助。

要小心,DVCS将库作为一个单元处理。 您可以提交逐个文件(使用filter),但是它们针对整个存储库存储更改。 它混淆了cvs(svn)用户的单一文件更改更加规则。

拥有多个克隆的另一个很好的理由(至less如果你有多台计算机)是你很容易看到你是否已经引入了任何依赖到你的代码。 (也就是说,你的代码会在另一台机器上运行,而这台机器可能没有主工作站所有的开发包)

我build议你阅读这个链接 ,其中概述了你可以实施SCC的各种方法,并select适合你的需求的方法

像Mercurial这样的DVC以及Bazaar和Git–已经使得许多东西便宜,使得一个军队可以从扩大的能力中受益。

  1. 如果您保持工作分支处于最新状态或closures主线,并将您的所有增量数据同步到DVC中,则您可以快速尝试“一次性”代码。

    代码只是无忧而已,实际上它可以提供一个心理上的自由来尝试多种解决scheme,然后再select首选解决scheme。

  2. 有些人为他们实现的每个function(特别是在git中)分支,无论大小如何。 在mercurial中,这种开发方式很便宜,那么为什么不使用这个function呢? 所以这可能意味着每天多次提交更大的提交。

    一个。 如果采用这种方法,则可能需要在工作日结束时将更改推送到脱离主机的回购站,以涵盖当天所做的工作 与WHS发生备份的时间之间的时间。

    湾 我已经在我的WHS上安装了CopSSH ,它的工作原理非常奇妙,它提供了大约5MB的SSH / SFTP / SCPfunction。 在此之前,我在Virtual Server 2005上运行Ubuntu Linux,以提供类似的function。 你可以通过ssh将你的mercurial推到WHS box

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

当我想让一些可重用的组件可用于其他项目时,我将这些存储库分开。 我configuration了,当我提交时,它也会自动推送(我用Tortoise HG插件),因为有时我忘了推,当移动地理我需要的代码,明白吗?

所以,这是我的提示。