我决定将 Mercurial 用于一个小型的个人项目。
我读过的大部分帮助都是关于合并多个用户之间的更改。因为我是独奏，这不会发生。
我应该有多个存储库吗？我的开发计算机已经每晚都备份到我的 Windows Home Server，所以在别处有第二个存储库只是为了备份目的似乎没有什么价值。
我应该每天分支吗？或者只是在发布附近？还是什么时候？
一般来说，您建议单独使用 Mercurial 的开发人员采取哪些做法？
Jay Bazuzi
问问题
6136 次
13 回答
35
我使用 Mercurial 开发 FsCheck，这是一个托管在 codeplex 中的单元测试框架。我目前是唯一的开发人员，但偶尔会有人给我发补丁。
具体来说，我的文件系统中有一个名为“FsCheck”的文件夹。在那，我有一个存储库，因此有一个名为 main 的文件夹。通常，我在处理特定功能或错误修复或其他任何内容的文件夹旁边有几个文件夹，例如错误转义异常和功能状态检查和补丁用户Foo。这些是使用 hg clone 创建的。
当我完成某个功能或错误修复后，我会提交该文件夹中的所有内容并推送到 main。可能合并到main中。（hg 提交、hg 推送、hg 合并）。然后我删除了文件夹（小心使用 hg status 和 hg dedicated ，我不会丢掉有用的东西）。
我几乎从不在 main 工作，除非在发布之前进行最后的清理（比如文档）。在发布之前，我在 main 中标记了发布号（hg tag v0.5.1）。
Codeplex 使用 svn 作为源控制。我只使用它来存储版本，为此我使用本地签出的 SVN 工作副本，我使用 hg 存档将 Mercurial 存储库复制到其中。然后使用 svn 提交。原始的，但它可以工作（在我看来，在 Windows 上使用 Mercurial 作为 SVN“超级客户端”还不是很友好）
我还不需要对以前的版本进行维护，但我会通过从该版本的修订版中克隆主存储库来做到这一点（这很容易，因为我标记了它），并在那个单独的存储库中工作。合并回主干就像将更改推送到主干并合并一样容易。
总之：
- 一个文件夹，用于存储您的所有项目的存储库，以及您的项目名称
- 在该文件夹中，每个“工作单元”有一个主存储库和一个临时存储库，并带有工作单元的描述性名称。
这很好，因为您的分支和您正在处理的内容在文件系统中直观可见。
于 2009-03-01T17:39:13.460 回答
29
从你的问题的措辞来看，我认为你可能对版本控制术语有一些误解。
每个项目都应该有一个存储库。您可以将存储库简单地视为文件系统上的文件夹。当您在特定文件夹中初始化 Mercurial 存储库时，该文件夹中的每个文件及其任何子文件夹都有资格添加到存储库以进行版本控制。您不一定要添加所有内容，但如果您愿意，可以添加任何内容。
如果您愿意，可以将此本地存储库推送到远程存储库，作为备份形式或作为与他人共享代码的方法。但如果它只是一个个人项目，这很可能没有必要，特别是因为您已经有了一个备份解决方案。
分支通常用于将项目的不同“版本”分开。正如一些人所提到的，这对于作为独立开发人员尝试重构代码的方法或测试特定问题的不同方法时很有用。如果它不成功，你不必担心找出回滚到哪里，你只需烧掉分支。如果它确实有效，则将分支合并回主存储库（“主干”）并继续。
如果您确实到了“发布”代码的地步，并且需要继续维护旧版本，那么您还需要使用分支。例如，假设您发布了 1.0 版，并且有人开始使用它。当他们使用它时，您私下继续努力开发下一个版本，可能是 1.1，在您的主干存储库中添加功能。现在，有人在已发布的 1.0 代码中发现了一个错误，您需要修复它，但您不能只在主干中修复它并给他们该代码，因为它处于没有发布的状态。这就是 1.0 分支派上用场的地方。您可以修复 1.0 分支中的错误，并将错误修复更改合并到主干中，以便在那里修复错误。然后您可以使用错误修复重新打包 1.0 并将其发布给您的用户，
除此之外，使用 Mercurial 独奏通常不会涉及很多花哨的工作。做一些工作，当你完成一个特性时，提交它给自己一个“检查点”，如果需要，你可以在未来返回。您不需要每次保存或类似的东西时都提交，只要在您觉得添加了一些重要的东西时就这样做。如果您需要回顾它，这将为您提供该项目的良好历史。
有关更多信息，我强烈建议您花点时间阅读这本书：分布式修订控制与 Mercurial。您不必阅读高级主题，但至少阅读第 1-5 章和第 8 章可以很好地介绍 Mercurial 和一般的版本控制。
于 2009-02-24T07:21:50.553 回答
5
我使用了不同于 Mercurial 的另一个分布式版本控制系统，但我怀疑这是否重要。
在我的个人项目中，我大量使用分支。我通常有一个主要的开发分支（“主干”），它应该始终有一个工作版本。我的意思是单元测试和其他自动化测试通过，并且所有代码都通过这些测试进行测试，除了我明确排除在测试覆盖范围之外的小部分。这确保了行李箱始终处于良好的状态以供进一步发展。
每当我开始进行更改时，我都会从主干分支创建一个新分支。这给了我自由破解的自由。例如，我可能不担心通过这个分支的自动化测试。由于它是一个孤立的区域，我可以随意提交，而且我确实这样做了：微提交是我最喜欢的分布式版本控制功能。分支中的工作完成后，我将其合并回主干。
这种工作方式的好处是，如果事实证明我正在进行的更改是一个坏主意，我可以轻松退出。事实上，没有什么可以退出的，因为更改尚未合并。
有时我很懒，不会为我正在开发的一些新事物创建新分支。当我需要比预期更多的时间来完成工作时，事实总是证明这是一个错误。当我需要在此过程中进行另一个不相关的更改时，情况会变得更糟。当我遵循 all-work-in-its-own-branch 风格时，可以在自己的分支中完成不相关的更改，合并到主干中，然后如果需要，另一个分支可以合并来自主干的更改。
于 2009-02-24T07:44:27.363 回答
5
我每天都使用 Mercurial，请参见此处，我还在少数支持 Mercurial 的免费托管服务之一ShareSource（我在积分页面上）提供帮助。自从Xen放弃 BitKeeper以来，我一直在使用 HG 。
我会建议你，对于个人项目，不惜一切代价避免分支。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 等时对它感兴趣。
于 2009-02-24T07:48:49.133 回答
3
这些通常与您从事任何软件项目的工作相同。简单地拥有或不拥有版本控制超出了任何讨论范围；）
通常，您只需在功能准备就绪时提交。由于您有备份，因此您无需每天提交即可安全地存储您的工作。
对于分支：在我的个人项目中，我主要使用它来尝试想法，例如。当我对同一问题有另一种解决方案时。为此，我也喜欢 Git 的 stash 命令。
但是我确实有多个存储库。我有一个带有 shell 访问权限的主机，我推送到该主机。因此，无论我在哪里工作和拥有任何工作站（在工作中：当我有时间编写代码时，在家里的桌面上以及在父母家时在笔记本电脑上时），我都可以与该存储库同步。
于 2008-11-10T07:01:02.960 回答
2
于 2008-11-10T06:50:10.270 回答
1
我之前使用 CVS、Perforce、Subversion 作为我的个人版本控制系统，大约两周前开始使用 Mercurial :-) 在工作中我们使用 MS Team System ...
对我来说，最值得注意的新事物是不同机器之间的轻松传输。在工作中，我在一个 mercurial repo 中有一些东西（使用 hg 作为团队系统的超级客户端）。我定期将所有更改推入/拉出笔记本电脑，因此我在两台机器上都有完整的历史记录。
在家里，我也从笔记本电脑推/拉回购。
因此，我可以在任何地方工作（家庭办公室使用强大的计算机，在路上使用笔记本电脑或在工作中），而不必担心我是否会丢失更改。好的，偶尔我需要合并两个更改，但这很少会造成伤害……恕我直言，hg 做得很好。
此外，使用 mercurial 的“设置成本”非常低。您阅读了教程，安装它，说“hg init”并继续工作。无需再决定某些东西是否属于您的神圣 SVN 服务器，放在哪里等等。Mercurial 的“摩擦”比 SVN 的低一点。
于 2009-03-03T14:20:57.540 回答
0
我认为这取决于您是否同时维护现有应用程序并添加功能（或修复大错误）。
这样，您可以在主分支中修复错误，同时在其自己的分支中创建新功能。
我对我的应用程序就是这样做的，但使用的是本地版本的 CVS。此外，如果您的团队中添加了新的开发人员，您就可以开始了。
我同意这是与备份不同的问题。
祝你好运，
兰迪·施泰格鲍尔
于 2008-11-10T19:46:35.710 回答
0
SCM 是编辑器的一种“智能”撤消缓冲区扩展。您可以回到过去，您可能已经解决了一个问题，但删除了它，因为它已被重构，但您将再次需要解决方案，等等。设置一个视觉差异，它会告诉您自上次以来您所做的更改提交或在过去两天里，如果我不喜欢我的旧解决方案，我会不断审查我的代码并更改它。
分支正在处理流：当您开始朝一个方向前进，但它需要更多思考，同时您想从事其他工作时，它会有所帮助。
请注意，DVCS 将存储库作为一个单元处理。您可以逐个文件提交（使用过滤器），但它们会将更改存储在整个存储库中。它使 cvs (svn) 用户感到困惑，因为单个文件更改更规律。
于 2008-11-17T04:04:31.233 回答
0
拥有多个克隆的另一个很好的理由（至少如果你有不止一台计算机）是你很容易看到你是否在你的代码中引入了任何依赖项。（即您的代码将在另一台机器上运行，它可能没有您的主工作站拥有的所有开发包）
于 2009-02-19T11:55:42.027 回答
0
我建议您阅读此链接，其中概述了您可以实施 SCC 的各种方法，并选择最适合您需求的方法
于 2009-02-27T07:06:07.900 回答
0
像 Mercurial 和 Bazaar 和 Git 这样的 DVC 已经使许多东西变得便宜，这样一支军队就可以从扩展的功能中受益。
如果您保持纪律以使工作分支保持最新或脱离主线并将所有增量有意义地同步到 DVC 中，则您可以快速尝试“一次性”代码。
代码流畅无忧，实际上它可以提供一种精神上的自由来尝试多种解决方案，然后再选择首选解决方案。
有些人为他们实现的每个功能（尤其是在 git 中）创建分支，无论其大小。在 mercurial 中，这种开发方法很便宜，那么为什么不使用该功能呢？所以这可能意味着每天多次提交较小的提交和较大的提交。
一种。如果您采用这种方法，您可能希望在工作日结束时将更改推送到主机外存储库，以涵盖 当天完成的工作与发生 WHS 备份的时间之间的时间。
湾。我已经在我的 WHS 上安装了CopSSH，它在大约 5MB 中为 Windows 框提供了 SSH/SFTP/SCP 功能。在此之前，我在 Virtual Server 2005 上运行 Ubuntu Linux，以提供类似的功能等服务。 您可以通过 ssh 将您的 mercurial 推送到 WHS 框
于 2009-03-02T08:38:22.333 回答
0
我总是使用 Git 或 Mercurial，即使是单独使用。
当我想让一些可重用的组件可用于其他项目时，我会分离存储库。我配置为当我提交时，它也会自动推送（我使用 Tortoise HG 插件），因为有时我忘记推送，而当我在地理上移动时我需要那个代码，明白吗？
所以，这是我的建议。
于 2010-11-16T18:35:05.567 回答