Mercurial（我猜是 Git）和 Dropbox：有啥缺点吗？

Posted 2023-02-18

【中文标题】Mercurial（我猜是 Git）和 Dropbox：有啥缺点吗？

【英文标题】：Mercurial (and, I guess Git) with Dropbox: any drawbacks?Mercurial（我猜是 Git）和 Dropbox：有什么缺点吗？

【发布时间】：2010-12-30 04:16:18

【问题描述】：

我有一个用于个人项目的 Mercurial 存储库，我已经在我的 Dropbox 中存储了几个星期的主存储库（类似于this line；我知道它也是possible with git）。

这个想法是，它既可以作为一种与多台机器一起工作的方式，也可以作为远程备份。 我克隆存储库并处理非 Dropbox 副本，并且只偶尔推送一次更新，就像我想使用 Bitbucket 一样。

与使用专用托管（在 Mercurial 的情况下为 BitBucket）相比，您能想到这个想法的任何缺点吗？ 我知道 Bitbucket 有针对单个用户的免费帐户，这很棒，但它们被限制在 150M，这不是很大。

特别是，Dropbox 的同步过程是否会损坏存储库？我必须在主存储库上运行一次 hg recover，但它可能是无关的（无论如何它很高兴恢复）。有没有人对这个想法有不好的体验？有没有人有更长的好经验，可以减轻我的后顾之忧？有没有人基于更好地理解这些事物的内部而提出意见？

编辑：我对问题进行了一些澄清。它们是斜体。

【问题讨论】：

为什么不使用 bitbucket？ ://

在推送到 Dropbox 之前，告诉 Dropbox暂停同步。然后推。在恢复同步之前，记下确切的时间，这样您就可以在 Dropbox 网站中找到这批更改，以防万一发生不好的事情并且您想恢复更改。多次推送后，执行git gc 以保持 repo 中的文件数最少。

请注意，bitbucket 的私有存储库不再有 150MB 的限制。现在的限制是 5 名开发人员可以访问该存储库。

【参考方案1】：

如果您尝试在同步过程中访问存储库，我预计会出现问题。这似乎也有点开销。你真的不需要同步你同步的东西。我不知道 Dropbox 如何处理冲突，但我怀疑它能否以支持 scm 的方式处理。

【参考方案2】：

我想这对于一两台机器上的个人项目来说可能没问题，但实际上你会想要为多成员项目使用专业托管。

我个人使用 BitBucket 已经有一段时间了，非常高兴……您也可以在免费帐户上拥有一个私人项目。

【讨论】：

截至 2012 年 1 月 13 日，您可以在 Bitbucket.org 上拥有无限的私人项目，但您的整个帐户只能有 5 个提交者。因此，只要您的团队不超过 6 人，您就可以开始了。

【参考方案3】：

+1 表示比特桶。它是免费的，您可以使用该免费帐户获得一个私人仓库（与 github 不同）。

仅使用保管箱的解决方案的缺点是，如果您确实在计算机上的存储库中搞砸了，那么搞砸的东西将被复制到 bitbucket 并复制到您安装了保管箱的所有其他地方。 Dropbox 速度非常快，因此您将无法及时阻止它发生以防止出现问题。

您无法将对存储库的更改与发布这些更改分开。

我确实使用 Dropbox 来托管我在家庭和工作机器上使用的几个存储库，但这些并不是这些存储库的唯一副本。还有一个 bitbucket 存储库（以及其他克隆它们的人）。

【讨论】：

这个想法是将保管箱副本用作“主”并实际使用本地克隆。所以保管箱不是唯一的副本。也许我应该将其编辑到问题中。

如果保管箱外至少有一个克隆/副本，它应该可以正常工作。我使用一些个人笔记存储库来做这件事，这些存储库每晚都会在 Dropbox 之外备份。

【参考方案4】：

我在个人项目中使用 Dropbox 和 git 已经有一段时间了，我还没有遇到任何问题。不过，有时您必须等待 Dropbox 同步。我认为如果有多个人在同一个项目上工作，这可能会导致一些小问题，但对于个人项目，我发现 Dropbox 甚至比 GitHub 更好，如果仅仅是因为推送/pulling 更快。

至于推送/拉取中间同步，这很可能会导致问题，甚至可能损坏您的存储库，但如果您是该项目的唯一工作人员，那么您确切知道 Dropbox 何时同步。

【讨论】：

我假设您只是推拉到 git 认为的本地存储库，使用 Dropbox 时不需要“远程”的概念对吗？

这看起来不错。我会尝试看看是否可以以编程方式停止/启动 Dropbox，然后将整个内容包装到每日 crontab 脚本中。

【参考方案5】：

出于上述原因，我建议不要这样做，但要更加严格地说明。 mercurial 和 git 都有自己的协议，用于在存储库之间移动变更集。这些协议针对以下情况进行了优化/构建：

效率 一致性（永远不能从处于半更新状态的存储库中提取） 钩子/触发器——在推/拉上做事，包括质量（不允许标签等）过滤器

如果您只是让目录同步来处理 .hg（或 .git）目录的同步，那么在同步期间，您会得到一个处于不一致状态且不知道的远程存储。

此外，hg 和 git 在它们的磁盘状态中都区分了哪些是本地的，哪些是远程的。他们知道要分享哪些信息（例如：提交的变更集）和不分享哪些信息（例如：当前的本地工作目录父修订版）。

在其他答案中，人们会说“你可能会没事”或“我从来没有遇到过问题”，这可能是真的，但不能保证是真的，而且修订控制不是一个赌注的地方.为您的源代码控制系统使用适当、更好、更安全、更高效、功能更全的同步协议。

【参考方案6】：

我的 Dropbox 存储库损坏时遇到了问题。它不会一直发生，但它不止一次发生的事实意味着我将停止为此目的使用 Dropbox。

也就是说，Dropbox 肯定比获得真正的托管便宜，所以只要您保留备份，您可能会发现它可以用于个人项目。

【讨论】：

+1 在短时间内创建和删除大量文件（例如锁定文件）时，Dropbox 似乎会感到困惑。

【参考方案7】：

我不建议将 Dropbox 与 mercurial 一起使用，因为我经常看到我的 Mac 和 Windows 客户端之间存在冲突的文件。特别是撤消受到​​影响，但我确实也遇到了与其他文件的冲突。

问候 米尔科

【参考方案8】：

我目前在 3 台机器上将它与 Bazaar 一起使用。但是，我是所有分支中唯一的开发人员。

我使用了 init-repo --no-trees 命令来创建存储库。

【参考方案9】：

我也一直在使用带有 Hg 的 Dropbox，直到现在都没有遇到任何问题。太晚了，我意识到 hg 不会在例行检查期间报告损坏，只有当你尝试真正使用 repo 时（最糟糕的情况，因为在你真正需要它之前你不知道有什么东西坏了）。

不清楚损坏是自发的还是由使用 Mac、Windows 和 Linux 客户端访问存储库引起的（我在不同时间使用这三种客户端）。但我至少看到过一个只有 Mac 处于活动状态时发生的损坏案例，因此很可能是 Dropbox 本身。

如果您确实决定过着危险的生活，请定期运行“hg verify”（或“git verify”以发现任何污垢。

【参考方案10】：

对于那些更喜欢使用 Dropbox 而不是 bitbucket/github 的人，这是我为避免云备份服务的 2 路同步过程造成损坏而采取的措施：

我的本​​地代码文件夹是c:\code，备份文件夹是c:\Dropbox。在 Dropbox 文件夹中，我有一个 truecrypt 加密文件容器（它的大小比我的代码文件夹大得多）。白天，我会定期向本地 Git/Mercurial 存储库提交更改。但是最终，我退出了 Dropbox 并挂载了 truecrypt 文件容器。我将更改推送到文件容器中的裸存储库，卸载它并重新启动 Dropbox。

这样，我可以安全地使用云服务作为我的 DVCS 存储库的备份。如果文件容器正在使用中，Dropbox 将等待它被卸载，所以希望那里没有损坏的变化。尽管如此，如果我以某种方式获得了文件容器的冲突副本，我可以轻松地挂载这两个副本并比较变更集。