Mercurial (и, я думаю, Git) с Dropbox: любые недостатки?

У меня есть репозиторий Mercurial для личного проекта, и я храню главный репозиторий в моем Dropbox уже несколько недель (что-то вроде эта строка, и я понимаю это также возможно с git).

Идея заключается в том, что она служит как способ работы с несколькими машинами, так и как удаленная резервная копия. Я клонирую репозиторий и работаю над копией, отличной от Dropbox, и время от времени обновляю обновления, так же, как я полагаю, работает с Bitbucket.

Можете ли вы придумать какие-либо недостатки этой идеи, по сравнению с использованием выделенного хостинга (BitBucket в случае Mercurial)? Я знаю, что у Bitbucket есть бесплатные учетные записи для одиноких пользователей, что здорово, но они ограничены 150 миллионами, что не является огромным.

В частности, возможно ли, что процесс синхронизации Dropbox приведет к повреждению репозитория? Я должен был запустить hg восстановить один раз в основном хранилище, но он может быть не связан (и в любом случае он с радостью восстанавливается). Кто-нибудь имеет плохой опыт в этой идее? Кто-нибудь имеет более хороший опыт и может облегчить мои заботы? Кто-нибудь имеет мнение, основанное на лучшем понимании внутренних дел этих вещей?

edit: Я добавил некоторые пояснения к вопросам. Они выделены курсивом.

Ответ 1

Я бы посоветовал это по указанным выше причинам, но более решительно заявил. У обоих mercurial и git есть свои собственные протоколы для перемещения наборов изменений между репозиториями. Эти протоколы оптимизированы/построены для:

эффективность
Консистенция (никогда не сможете вытащить из репо в обновленном состоянии)
крючки/триггеры - делают вещи на push/pull, включая качество (без вкладок и т.д.).

Если вы просто разрешите синхронизацию каталогов обрабатывать хранение .hg(или .git) каталогов в синхронизации, то во время этой синхронизации у вас есть удаленное хранилище, которое находится в несогласованном состоянии и не знает его.

Кроме того, как hg, так и git имеют разделение того, что локально, и что удаленное - в порядке их дискового состояния. Они знают, какую информацию можно разделить (например: commited changesets), а что нет (пример: текущая, локальная рабочая версия родительской версии).

В других ответах люди говорят, что "вы, вероятно, будете в порядке" или "у меня никогда не было проблемы", и это, вероятно, так, но это не гарантируется, и контроль версий не является местом для игры., Используйте правильную, лучшую, безопасную, более эффективную и полнофункциональную синхронизацию для вашей системы управления версиями.

Ответ 2

У меня возникли проблемы с повреждением хранилищ Dropbox'ed. Это происходит не всегда, но тот факт, что это произошло более одного раза, означает, что я остановлюсь на использовании Dropbox для этой цели.

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

Ответ 3

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

Я лично использовал BitBucket в течение некоторого времени и был очень доволен... у вас также может быть один частный проект на бесплатной учетной записи.

Ответ 4

Я бы ожидал проблем, если вы попытаетесь получить доступ к репозиторию в середине синхронизации. Это также немного накладные расходы. Вам не нужно синхронизировать содержимое, которое вы синхронизируете. Я понятия не имею, как Dropbox обрабатывает конфликты, но я сомневаюсь, что он может сделать это с помощью scm-aware.

Ответ 5

+1 для битбакет. Это бесплатно, и вы получаете одно частное репо с этой бесплатной учетной записью (в отличие от github).

Недостатком решения Dropbox является то, что если вы нанесете что-то на репо на своей машине, эта ошибка будет скопирована на битбакет и реплицирована в любое другое место, где у вас установлен Dropbox. Dropbox очень быстрый, поэтому вы не сможете остановить его вовремя, чтобы предотвратить проблемы.

Вы теряете возможность отменить внесение изменений в репозиторий с публикацией этих изменений.

Я использую dropbox для размещения нескольких репозиториев, которые я использую как на домашних, так и на рабочих машинах, но это не единственные копии этих репозиториев. Там также битбокс репо (а также другие люди, у которых есть клоны).

Ответ 6

Я использовал Dropbox с Hg, не испытывая проблемы до сих пор. Слишком поздно я понял, что hg не сообщает о коррупции во время рутинных проверок, только когда вы пытаетесь использовать репо на самом деле (худшее из всех ситуаций, так как вы не знаете что-то сломанное, пока оно вам действительно не понадобится).

Неясно, является ли коррупция спонтанной или вызвана доступом к репозиторию с клиентами Mac, Windows и Linux (я использую все три в разное время). Но я видел, по крайней мере, один случай коррупции, когда активен только Mac, поэтому вполне может быть Dropbox.

Если вы решите жить опасно, запустите "hg verify" (или "git verify" регулярно, чтобы включить какую-либо грязь.

Ответ 7

Я использую Dropbox с git для личных проектов уже довольно давно, и у меня еще не было проблемы. Хотя, есть моменты, когда вам приходится ждать синхронизации Dropbox. Я думаю, что это может вызвать небольшие проблемы, если в одном проекте работает несколько человек, но для личных проектов я считаю Dropbox еще лучше, чем GitHub, хотя бы потому, что нажатие/вытягивание происходит быстрее.

Что касается нажатия/вытягивания mid-sync, это, скорее всего, вызовет проблемы, и это может даже повредить ваше репо, но если вы работаете только с одним проектом, тогда вы точно знаете, когда Dropbox будет синхронизироваться.

Ответ 8

Я бы не рекомендовал использовать dropbox с mercurial, так как часто вижу конфликтующие файлы между моими клиентами Mac и Windows. Особенно это касается отмены, но я также столкнулся с конфликтами с другими файлами.

Отношения Mirko

Ответ 9

Я использую его с Bazaar в данный момент через 3 машины. Тем не менее, я являюсь единственным разработчиком в любом из веток.

Я использовал команду init-repo --no-trees для создания репозитория.

Ответ 10

Для тех, кто предпочитает использовать Dropbox поверх bitbucket/github, вот что я делаю, чтобы избежать повреждения из процесса двусторонней синхронизации служб облачного резервного копирования:

Моя локальная папка кода c:\code, а папка резервного копирования - c:\Dropbox. Внутри папки Dropbox у меня есть truecrypt зашифрованный файловый контейнер (размер этого файла намного больше, чем моя папка кода). В течение дня я регулярно совершаю изменения в локальном хранилище Git/Mercurial. Однако в конце дня я выхожу из Dropbox и монтирую контейнер файла truecrypt. Я ввожу изменения в голый репозиторий в контейнере файлов, отключает его и снова запускает Dropbox.

Таким образом, я могу безопасно использовать облачный сервис для работы в качестве резервной копии моего репозитория DVCS. Если контейнер файлов используется, Dropbox будет ожидать, что он будет размонтирован так надежно, там нет изменений в коррупции. Тем не менее, если я каким-то образом получаю противоречивую копию файлового контейнера, я могу легко монтировать и копии, и сравнивать набор изменений.