Упаковка Dropbox с Mercurial для контроля версий - сумасшедшая идея?

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 испытывает сердечный приступ, начинающийся с десятков тысяч файлов каждый раз, когда он ищет изменения / новые файлыдобавить.

Это означает, что он не будет обнаруживать новые файлы и в существующих проектах, что является незначительной болью в шее - было бы замечательно, если бы Mercurial действительно имел фильтр INCLUDE в такие моменты времени...

pps У меня была прекрасная идея, чтобы сделать этот бит немного проще.

Я создал новую папку вне Dropbox под названием «Репо» и внутри нее я создал соединение каталогов (ссылка навы * nix типы) в каталог внутри моего Dropbox, который содержит весь мой исходный код (мой каталог Eclipse Workspace - в основном).

Затем я помещаю свое хранилище в папку 'repo' - таким образом, этоне наблюдая за всем моим Dropbox, только за частью, которую я хочу, и она все еще не «внутри» моего Dropbox;)

Answer 1

Как вы указали, основным недостатком этого подхода является то, что вы привязаны к одному репозиторию. Одним из больших преимуществ распределенных систем контроля версий, таких как Mercurial, является то, что репозитории дешевы в создании и использовании для небольших изолированных проектов.

Почему бы просто не использовать bitbucket.org для ваших нужд контроля версий? Вы можете создать столько частных репозиториев, сколько захотите, и использовать столько дисков, сколько захотите. Единственным недостатком здесь является то, что вы ограничены количеством пользователей, с которыми вы можете поделиться ими, но с учетом подхода, который вы обрисовали выше, это не проблема.

Answer 2

Mercurial жестко кодирует корневой каталог на том же уровне, что и рабочий каталог, поэтому я не думаю, что вы можете изменить это.

Однако вы можете сделать символическую ссылку каталога .hg на другой каталог:

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

Mercurial будет следовать по символической ссылке и работать в обычном режиме, но, вероятно, Dropbox (если он ведет себя разумно) не будет. Когда вы сделаете это, убедитесь, что никогда не выполняете никаких операций в WORK FOLDER, потому что это все испортит.

Если честно, я бы не стал рекомендовать этот вид рабочего процесса, хотя он кажется хрупким.

Answer 3

Вы не будете страдать от повреждения хранилища, которое вы видите при хранении каталога .hg в Dropbox, но вы, вероятно, в конечном итоге будете совершать меньше, что тоже облом.