CODEWITHSUNDEEP
version-controlmercurialrepositorydropbox
user834595
user834595

Reputation:

Wrapping Dropbox with Mercurial for version control - crazy idea?

I currently use Dropbox as my "backup" solution for source and resources - and it's fine and dandy and has saved my bacon many times.

I find myself in need of a proper version control system now tho - and I really don't want to put a repository INSIDE my Dropbox folder.

For one thing, it will fill my Dropbox allowance pretty quickly - for another, I don't really want Dropbox and the version-control software 'fighting' over files.

So I'm thinking of doing something like this (I'm using Mercurial but I'm sure the same theory applies to other VC stuff)

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

That way, everything I work on is covered by Dropbox - but my version control is outside of Dropbox.

Obviously not every file in my DROPBOX folder is version controlled - and I'm stuck with only 1 Repository for ALL my work (not ideal) but can anyone see any other snags with this approach?

Note: MYDOCS is backed-up separately (much less often) so there's no risk of file loss here.

p.s.

I spent a bit of time over the weekend implementing this (using Mercurial/TortoiseHG) and it seems to work quite well.

There are some snags - you have to set aggressive ignore filters (in the end I just used "*" and added code manually) otherwise TortoiseHG has a heart-attack staring at 10s of 1000s of files every time it looks for changes/new files to add.

This means it won't spot new files in existing projects too which is a minor pain-in-the-neck - it would be great if Mercurial actually had an INCLUDE filter at times like this...

p.p.s. I had a bright idea to make this a BIT easier.

I created a new folder outside the Dropbox called "Repo" and inside that I created a Directory Junction (link for you *nix types) to the directory inside my Dropbox which contains all my source (my Eclipse Workspace directory - basically).

I then put my repo into the 'repo' folder - that way it's not overseeing my entire Dropbox, just the part of it I want it to - and it's still not 'inside' my Dropbox ;)

Upvotes: 3

Views: 951

Answers (3)

Laurens Holst
Laurens Holst

Reputation: 21036

Mercurial hard-codes the root to be on the same level as the working directory, so I don’t think you can change this.

What you could do however is to symlink the .hg directory to another directory:

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

Mercurial will follow the symbolic link and operate as normal, but probably Dropbox (if it’s behaving sanely) won’t. When you do this, make sure to never do any operations in WORK FOLDER because that will mess things up.

To be honest I wouldn’t recommend this kind of workflow though, it seems fragile.

Upvotes: 0

Ry4an Brase
Ry4an Brase

Reputation: 78340

You won't suffer the repository corruption one sees when keeping the .hg directory in Dropbox, but you'll probably end up committing less which is a bummer too.

Upvotes: 0

Chris Phillips
Chris Phillips

Reputation: 12387

As you point out, the major drawback of this approach is that you're tied to a single repository. One of the big advantages of distributed version control systems like Mercurial is that repositories are cheap to create and use for isolated little projects.

Why not just use bitbucket.org for your version control needs? You can create as many private repositories as you want and use as much disk as you want. The only drawback here is that you're limited to how many users you can share them with, but given the approach you outlined above, that doesn't seem to be a problem.

Upvotes: 4

Related Questions