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

时间:2008-11-10 06:34:04

标签: version-control mercurial

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

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

我应该拥有多个存储库吗?我的开发计算机已经每晚备份到我的Windows Home Server,因此在其他位置备份第二个存储库似乎没有用于备份目的。

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

一般来说,对于使用Mercurial的单独开发人员,您推荐哪些做法?

13 个答案:

答案 0 :(得分:35)

我使用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'超级客户'在我的意见中不是非常用户友好)

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

总结:

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

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

答案 1 :(得分:29)

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

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

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

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

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

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

有关详细信息,我强烈建议您花些时间阅读本书:Distributed revision control with Mercurial。您不必阅读高级主题,但至少阅读第1-5章和第8章将为您提供Mercurial和版本控制的一般介绍。

答案 2 :(得分:5)

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

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

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

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

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

答案 3 :(得分:5)

我每天都使用Mercurial,请参阅here,我也帮助了一些支持Mercurial的免费托管服务ShareSource(我在信用页面上)。我一直在使用HG,因为Xen删除了BitKeeper。

我会建议你,对于个人项目,不惜一切代价避免分支机构。 Mercurial的idea of what a branch is与您的预期有很大不同。像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 to manage a web site,在设置密钥,hgrc等时可能会发现它很有用。

答案 4 :(得分:3)

这些通常与您在任何软件项目上的工作相同。简单地拥有或不拥有版本控制超出了任何讨论范围;)

通常您只需在功能准备就绪时提交。由于您有备份,因此您无需每天提交,只是为了安全地存储您的工作。

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

但是我确实有多个存储库。我有一个托管shell访问,我推动。所以无论我在哪里工作,我都可以与那个仓库同步(在工作中:当我有时间编码时,在家里的桌面上以及在父母家里的lappy)。

答案 5 :(得分:2)

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

也许你会为自己分支,如果你想调查一个功能而又不想在主代码分支中加扰。

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

答案 6 :(得分:1)

我之前使用过CVS,Perforce,Subversion作为我的个人版本控制系统,并且大约两周前去了Mercurial :-)在工作中我们使用MS Team System ......

对我而言,最值得注意的新事物是在不同机器之间轻松转移。在工作中,我有一个mercurial repo中的东西(使用hg作为针对Team System的超级客户端)。我定期向/从我的笔记本电脑推送/拉出所有更改,以便我在两台机器上都有完整的历史记录。

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

因此,我可以在任何地方工作(家庭办公室使用强壮的电脑,在路上使用笔记本电脑或在工作中)而不用担心我是否会失去变化。好的,偶尔我需要合并两个更改,但这很少会伤害... hg很好地恕我直言。

此外,mercurial的“设置成本”非常低。你阅读了一个教程,安装它,说“hg init”然后继续工作。如果有什么东西属于你神圣的SVN服务器,把它放在哪里等等,就不会再解决了。 Mercurial的“摩擦”略低于SVN。

答案 7 :(得分:0)

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

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

我使用我的应用程序,但使用本地版本的CVS。此外,如果您的团队中添加了新的开发人员,那么您已准备就绪。

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

祝你好运,
兰迪斯蒂鲍尔

答案 8 :(得分:0)

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

分支正在开发流:当你开始向一个方向前进,但它需要更多的思考,同时你想要处理其他事情,那么它可以帮助。

请注意,DVCS将存储库作为一个单元处理。您可以逐个文件地提交(使用过滤器),但它们会针对整个存储库存储更改。它使单个文件更改更常规的cvs(svn)用户感到困惑。

答案 9 :(得分:0)

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

答案 10 :(得分:0)

我建议您read this link概述实施SCC的各种方法,并选择最符合您需求的方法

答案 11 :(得分:0)

像Mercurial这样的DVC--以及Bazaar和Git--已经制造了许多便宜的东西,以便一支军队可以从扩展的能力中受益。

  1. 您可以快速进行实验 如果你维护的话,“一次性”代码 保持工作的纪律 分支最新或主线 并同步所有你的 deltas有意义地进入DVC。

    代码只是毫无顾虑地流动,实际上 可以提供一个尝试多重的心理自由 解决首选问题之前的解决方案。

  2. 有些人为每个人分支 他们实现的功能(特别是在git中), 无论多大或多小。在 mercurial,这种发展方式 很便宜,所以为什么不用 能力?所以这可能意味着微小的提交 每天都要做几次大的提交。

    一个。如果你采用这种方法,你可能会想要    最后将更改推送到主机外的回购    工作日为了弥补之间的时间    当天完成的工作备份的时间    WHS发生

    湾我已经在我的WHS上安装了 CopSSH ,但它确实有效    奇妙地提供SSH / SFTP / SCP功能    在~5MB的窗口框。在那之前我是    在Virtual Server 2005上运行Ubuntu Linux    除其他服务外,提供类似的服务    功能。 你可以把你的善变推向    ssh上的WHS框

答案 12 :(得分:0)

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

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

所以,这是我的提示。