用 Mercurial 包装 Dropbox 进行版本控制 - 疯狂的想法？

Question

我目前使用 Dropbox 作为我的源代码和资源的“备份”解决方案 - 它很好而且很漂亮，并且多次拯救了我的生活。

我发现自己现在需要一个合适的版本控制系统 - 而且我真的不想将存储库放在我的 Dropbox 文件夹中。

一方面，它很快就能填满我的 Dropbox 津贴；另一方面，我真的不希望 Dropbox 和版本控制软件为文件“争斗”。

所以我正在考虑做这样的事情（我正在使用 Mercurial，但我确信同样的理论也适用于其他 VC 的东西）

MYDOCS Folder <-- this is where the repo will go
    .hg (for Mercurial in this case)
    DROPBOX Folder
        WORK FOLDER
            PROJECT1
            PROJECT2
            PROJECT3
            ...

这样，我所做的一切都由 Dropbox 覆盖 - 但我的版本控制在 Dropbox 之外。

显然，并不是 DROPBOX 文件夹中的每个文件都是版本控制的 - 而且我的所有工作都只有 1 个存储库（不理想），但是任何人都可以看到这种方法的任何其他障碍吗？

注意：MYDOCS 是单独备份的（频率要低得多），因此不存在文件丢失的风险。

ps

我周末花了一些时间来实现这个（使用 Mercurial/TortoiseHG），它似乎工作得很好。

有一些障碍 - 你必须设置积极的忽略过滤器（最后我只是使用了“*”并手动添加了代码），否则 TortoiseHG 每次查找更改/新文件时都会盯着 10 个或 1000 个文件进行心脏病发作添加。

这意味着它也不会在现有项目中发现新文件，这是一个小麻烦 - 如果 Mercurial 在像这样的时候实际上有一个 INCLUDE 过滤器，那就太好了......

pps 我有一个好主意让这变得更容易一点。

我在 Dropbox 外部创建了一个名为“Repo”的新文件夹，并在其中创建了一个指向 Dropbox 内目录的目录连接（*nix 类型的链接），其中包含我的所有源代码（基本上是我的 Eclipse Workspace 目录）。

然后，我将我的存储库放入“repo”文件夹中 - 这样它就不会监督我的整个 Dropbox，而只是监督我想要的部分 - 而且它仍然不在我的 Dropbox “内部”；）

Answer 1

正如您所指出的，这种方法的主要缺点是您被绑定到单个存储库。像 Mercurial 这样的分布式版本控制系统的一大优点是，对于独立的小项目来说，创建和使用存储库的成本很低。

为什么不直接使用 bitbucket.org 来满足您的版本控制需求？您可以根据需要创建任意数量的私有存储库并使用任意数量的磁盘。这里唯一的缺点是您可以与多少用户共享它们，但考虑到您上面概述的方法，这似乎不是问题。

Answer 2

将 .hg 目录保存在 Dropbox 中时，您不会遇到存储库损坏的情况，但您最终可能会减少提交，这也是一件令人遗憾的事情。

Answer 3

Mercurial 将根目录硬编码为与工作目录处于同一级别，因此我认为您无法更改此设置。

然而，您可以做的是将 .hg 目录符号链接到另一个目录：

cd WORK_FOLDER
ln -s ../MYDOCS_Folder/.hg .hg
hg up null   # to reset the dirstate
hg up

Mercurial 将遵循符号链接并正常运行，但 Dropbox（如果运行正常）可能不会。当您执行此操作时，请确保永远不要在 WORK FOLDER 中执行任何操作，因为这会使事情变得混乱。

老实说，我不推荐这种工作流程，因为它看起来很脆弱。