git - Mercurial(我猜是 Git)和 Dropbox : any drawbacks?

Question

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

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

与使用专用托管(Mercurial 中的 BitBucket)相比，您能想到这个想法有什么缺点吗？ 我知道 Bitbucket 为单个用户提供免费帐户，这很棒，但它们被限制为 150M，这不是很大。

特别是，Dropbox 的同步过程是否有可能破坏存储库？我不得不在主存储库上运行一次 hg recover，但它可能是无关的(无论如何它很高兴地恢复了)。有没有人对这个想法有不好的经验？有没有人有更长的好经验，可以减轻我的顾虑？有没有人基于对这些东西的内部结构的更好理解而发表意见？

编辑:我对问题进行了一些说明。它们是斜体。

Answer 1

出于上述原因，我建议不要这样做，但更强烈地说明了。 mercurial 和 git 都有自己的协议(protocol)，用于在存储库之间移动变更集。这些协议(protocol)针对以下方面进行了优化/构建:

• 效率
• 一致性(永远不能从半更新状态的 repo 中 pull )
• 钩子(Hook)/触发器——在推/pull 时执行操作，包括质量(不允许使用制表符等)过滤器

当您只是让目录同步处理 .hg(或 .git)目录同步的保持时，那么在该同步期间您会得到一个处于不一致状态并且不知道它的远程存储。

此外，hg 和 git 在它们的磁盘状态中区分了哪些是本地可用的，哪些是远程可用的。他们知道要共享哪些信息(例如:提交的变更集)以及不共享哪些信息(例如:当前的本地工作目录父版本)。

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