Mercurial 本地存储库备份
我非常喜欢备份。我将重要的学校论文等保存在 Dropbox 的文件夹中。我确保所有照片都复制到外部驱动器。我有一台家庭服务器，我在服务器内的两个驱动器上保存重要文件的镜像（如软件 RAID 1）。
所以对于我的代码，我一直使用 Subversion 来备份。我在 trunk 文件夹中保存了应用程序的稳定副本，但随后我创建了一个以我的用户名命名的分支，里面有我的工作副本。我在对该分支的提交之间做了很少的更改，因为我知道那里的代码是我的备份。
现在我正在研究 Mercurial，我必须承认我还没有真正使用过它，所以我可能全错了。但在我看来，你有一个服务器端存储库，然后你以本地存储库的形式将其克隆到工作目录。然后，当您处理某些内容时，您可以向该本地存储库提交内容，并且当内容处于与其他人共享的状态时，您可以hg推送到服务器上的父存储库。
在推送稳定、经过测试、无错误的代码之间，备份在哪里？
经过一番思考后，我得出的结论是，它并不用于备份目的，并且假设您已经自行处理了该问题。我想我需要将 Mercurial 本地存储库保留在我的保管箱或其他备份位置中，因为我正在进行的代码不会推送到服务器。
就这些了，还是我错过了什么？如果您使用 Mercurial，如何备份本地存储库？如果您今天早上打开计算机并且硬盘着火了（或者更可能的是读取头坏了，或者操作系统自身损坏了……），那么会丢失什么？如果您过去一周开发了一个模块，为其编写测试用例，对其进行记录和评论，然后病毒擦除了您的本地存储库，那么这不是唯一的副本吗？
那么，另一方面，您是否为每个本地存储库创建一个远程存储库并始终推送到它？
你如何找到平衡点？如何确保您的代码得到备份？使用 Mercurial 作为备份和使用本地文件系统备份实用程序来保证本地存储库的安全之间的界限在哪里？
I'm a big fan of backing things up. I keep my important school essays and such in a folder of my Dropbox. I make sure that all of my photos are duplicated to an external drive. I have a home server where I keep important files mirrored across two drives inside the server (like a software RAID 1).
So for my code, I have always used Subversion to back it up. I keep the trunk folder with a stable copy of my application, but then I create a branch named with my username, and inside there is my working copy. I make very few changes between commits to that branch, with the understanding that the code in there is my backup.
Now I'm looking into Mercurial, and I must admit I haven't truly used it yet so I may have this all wrong. But it seems to me that you have a server-side repository, and then you clone it to a working directory in the form of a local repository. Then as you work on something, you make commits to that local repository, and when things are in a state to be shared with others, you hg push to the parent repository on the server.
Between pushes of stable, tested, bug-free code, where is the backup?
After doing some thinking, I've come to the conclusion that it is not meant for backup purposes and it assumes you've handled that on your own. I guess I need to keep my Mercurial local repositories in my dropbox or some other backed-up location, since my in-progress code is not pushed to the server.
Is this pretty much it, or have I missed something? If you use Mercurial, how do you backup your local repositories? If you had turned on your computer this morning and your hard drive went up in flames (or, more likely, the read head went bad, or the OS corrupted itself, ...), what would be lost? If you spent the past week developing a module, writing test cases for it, documenting and commenting it, and then a virus wipes your local repository away, isn't that the only copy?
So then on the flip side, do you create a remote repository for every local repository and push to it all the time?
How do you find a balance? How do you ensure your code is backed up? Where is the line between using Mercurial as backup, and using a local filesystem backup utility to keep your local repositories safe?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将 Subversion 视为“备份”是可以的，但它只是在一台单独的机器上才真正做到这一点，这并不是 Subversion 真正固有的。如果你的 Subversion 服务器与你的开发机器是同一台机器（这在 Linux 世界中并不罕见），那么你并没有真正得到备份，以防止硬件故障、盗窃、火灾等。事实上，有一些在这种情况下，数据根本不备份 - 您当前的代码可能存在于两个位置，但存储库中的其他所有内容（例如修订历史记录）仅存在于远程服务器上的一个位置。
对于 Mercurial 来说，情况完全相同，只是您不再需要单独的服务器，因此您必须明确考虑备份，而不是需要在某处拥有服务器的副作用。您绝对可以在某处设置另一个 Mercurial 存储库，并定期将更改推送到该存储库，并将其视为您的备份。或者，只需以与备份任何其他重要目录相同的方式备份本地存储库即可。由于您在本地拥有存储库的完整副本，包括所有修订历史记录和其他元数据，这可以说比您当前使用 Subversion 的方式更加方便和安全。
It's ok thinking of Subversion as a 'backup', but it's only really doing that by virtue of being on a separate machine, which isn't really intrinsic to Subversion. If your Subversion server was the same machine as your development machine - not uncommon in the Linux world - you're not really backed up in the sense of having protection from hardware failure, theft, fire, etc. And in fact, there is some data in that case that is not backed up at all - your current code may exist in two places but everything else in the repository (eg. the revision history) only exists in one place, on the remote server.
It's exactly the same for Mercurial except that you've taken away the need for a separate server and thus made it so that you have to explicitly think about backing up rather than it being a side-effect of needing to have a server somewhere. You can definitely set up another Mercurial repository somewhere and push your changes to that periodically and consider that your backup. Alternatively, simply backup your local repository in the same way that you'd back up any other important directory. With you having a full copy of the repository locally, including all revision history and other meta data, this is arguably even more convenient and safe than the way you currently do it with Subversion.
“隐藏”.hg 目录存储所有本地提交。您可以使用标准备份程序备份此目录。
The "hidden" .hg directory stores all of the local commits. You can back up this directory using a standard backup program.
仅当您推送时，更改才会到达远程目录。提交保留在本地，但如果克隆存储库，您就可以获得它们。然后，是的，如果你希望你的东西到达服务器存储库，你必须“一直”推送到它。
另一方面，没有什么可以阻止您拥有多台机器并将内容从一台机器推送到另一台机器。每个 Mercurial 存储库都可以在几秒钟内输入“hgserve”将自己变成一个服务器。
我不确定它是否真的回答了你的问题，但我也非常喜欢备份并通过我的存储库的许多克隆来管理事物（我还大量使用 mq 在补丁模式下工作，但这是另一个故事）。
PS：作为旁注，我正在考虑使用 Mercurial 作为文件系统备份工具。唯一困扰我的是，为此目的，我更愿意禁用 diff 功能并将所有文件视为二进制文件，但这应该很容易。
The changes get to the remote directory only when you push. Commits stay local, but you get them if you clone your repository. Then, yes, if you want your things to get to the server repository you have to push to it "all the time".
On the other hand, nothing stops you to have several machines and push content from one to another. Every mercurial repository can turn itself into a server in a matter of seconds typing "hg serve".
I'm not sure it really answer to you question, but I too am a big fan of backup and manage things this way with many clones of my repository (I also use massively mq to work in patch mode but that's another story).
PS: as a sidenote, I'm considering to use mercurial as a tool for filesystem backup. The only thing that bother me is that for this purpose I would prefer to disable the diff feature and treat all files as binary, but that should be easy.