version-control - 用 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 是单独备份的(频率要低得多)，因此这里没有文件丢失的风险。

附:

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

有一些障碍 - 你必须设置积极的忽略过滤器(最后我只是使用“*”并手动添加代码)否则 TortoiseHG 每次查找更改时都会盯着 10 到 1000 的文件看/要添加的新文件。

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

p.p.s.我有一个好主意，可以让这更容易一些。

我在 Dropbox 外部创建了一个名为“Repo”的新文件夹，并在其中创建了一个目录连接(为您提供 *nix 类型的链接)到我的 Dropbox 中的目录，其中包含我的所有源代码(我的 Eclipse Workspace 目录 - 基本上) .

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

Answer 1

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

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