Mercurial (и, я думаю, Git) с Dropbox: какие-нибудь недостатки?
У меня есть хранилище Mercurial для личного проекта, и я уже несколько недель храню главный репозиторий в своем Dropbox (что-то в этом роде; и я понимаю, что это возможно и с помощью git).
Идея заключается в том, что он служит как для работы с несколькими компьютерами, так и для удаленного резервного копирования. Я клонирую репозиторий и работаю с не-Dropbox копией, и время от времени только загружаю обновления, так же, как я полагаю, я буду работать с Bitbucket.
Можете ли вы вспомнить какие-либо недостатки этой идеи по сравнению с использованием выделенного хостинга (BitBucket в случае Mercurial)? Я знаю, что у Bitbucket есть бесплатные аккаунты для отдельных пользователей, и это здорово, но они ограничены 150M, что не так уж и много.
В частности, возможно ли, что процесс синхронизации Dropbox повредит хранилище? Мне пришлось запустить hg recovery один раз в главном репозитории, но это может быть не связано (и в любом случае оно благополучно восстановлено). У кого-нибудь есть плохой опыт с идеей? У кого-нибудь есть хороший опыт, и он может облегчить мои заботы? У кого-нибудь есть мнение, основанное на лучшем понимании внутренних вещей этих вещей?
редактировать: я добавил некоторые пояснения к вопросам. Они выделены курсивом.
10 ответов
Я бы посоветовал против этого по причинам, изложенным выше, но более энергично изложенным. И Mercurial, и Git имеют свои собственные протоколы для перемещения наборов изменений между репозиториями. Эти протоколы оптимизированы / построены для:
- эффективность
- согласованность (вы никогда не сможете вытащить из репо в полуобновленном состоянии)
- ловушки / триггеры - выполнение заданий в режиме push / pull, включая фильтры качества (запрещены вкладки и т. д.)
Когда вы просто позволяете синхронизации каталогов обрабатывать синхронизацию каталогов.hg (или.git), то во время этой синхронизации вы получаете удаленное хранилище, которое находится в несогласованном состоянии и не знает об этом.
Кроме того, и hg, и git имеют разделение того, что только локально, а что удаленно, нормально в их состоянии диска. Они знают, какой информацией поделиться (пример: зафиксированные наборы изменений), а что нет (пример: текущая, ревизия родительского локального рабочего каталога).
В других ответах люди говорят: "С тобой, наверное, все будет в порядке" или "У меня никогда не было проблем", и это, скорее всего, правда, но это не гарантировано, и контроль версий не является местом, где можно играть шансы. Используйте правильный, лучший, безопасный, более эффективный, более полнофункциональный протокол синхронизации для вашей системы контроля версий.
У меня были проблемы с повреждением моих репозиториев Dropbox. Это не происходит постоянно, но тот факт, что это происходило не раз, означает, что я собираюсь прекратить использовать Dropbox для этой цели.
Тем не менее, Dropbox, безусловно, дешевле, чем получить реальный хостинг, поэтому, если вы сохраняете резервные копии, вы можете найти его приемлемым для личных проектов.
Я предполагаю, что это, вероятно, будет работать нормально для личных проектов на одной или двух машинах, но на самом деле вы захотите использовать профессиональный хостинг для проектов с несколькими участниками.
Я лично использовал BitBucket в течение некоторого времени и был очень доволен... у вас также может быть один частный проект на бесплатной учетной записи.
+1 для битбакета. Это бесплатно, и вы получаете одно частное репо с этой бесплатной учетной записью (в отличие от github).
Недостаток решения только для Dropbox заключается в том, что если вы что-то напортачите в репозитории на своей машине, этот провал будет скопирован в bitbucket и реплицирован в любое другое место, где вы установили Dropbox. Dropbox очень быстр, поэтому вы не сможете остановить его вовремя, чтобы предотвратить проблемы.
Вы теряете возможность разъединять внесение изменений в хранилище и публиковать эти изменения.
Я использую Dropbox для размещения нескольких репозиториев, которые я использую как на своем домашнем, так и на рабочем компьютере, но это не единственные копии этих репозиториев. Также есть репозиторий с битбакетом (как и другие люди, у которых есть их клоны).
Я ожидаю проблем, если вы попытаетесь получить доступ к хранилищу в середине синхронизации. Это также, кажется, немного накладных расходов. Вам не нужно синхронизировать данные, которые вы синхронизируете. Я понятия не имею, как Dropbox обрабатывает конфликты, но я сомневаюсь, что это может сделать это с учетом scm.
Я использую Dropbox с Hg тоже без проблем до сих пор. Слишком поздно я понял, что hg не сообщает о повреждениях во время рутинных проверок, только когда вы пытаетесь использовать репо по-настоящему (наихудшая из всех ситуаций, поскольку вы не знаете, что что-то сломалось, пока вам это действительно не нужно).
Неясно, является ли повреждение спонтанным или вызванным доступом к хранилищу с помощью клиентов Mac, Windows и Linux (я использую все три в разное время). Но я видел по крайней мере один случай коррупции, когда был активен только Mac, так что это вполне мог быть сам Dropbox.
Если вы решили жить опасно, регулярно запускайте команду "hg verify" (или "git verify"), чтобы найти любую грязь.
Я бы не рекомендовал использовать Dropbox с Mercurial, так как я часто вижу конфликтующие файлы между моими клиентами Mac и Windows. Особенно это касается отмены, но у меня тоже были конфликты с другими файлами.
С уважением Мирко
Я уже давно использую Dropbox с git для личных проектов, и у меня еще не было ни одной проблемы. Хотя иногда приходится ждать синхронизации Dropbox. Я думаю, что это может вызвать незначительные проблемы, если над одним и тем же проектом работают несколько человек, но для личных проектов я считаю, что Dropbox даже лучше, чем GitHub, хотя бы потому, что push /pull быстрее.
Что касается нажатия / вытягивания средней синхронизации, это, скорее всего, вызовет проблемы, и это может даже повредить репо, но если вы единственный, кто работает над проектом, то вы точно знаете, когда Dropbox будет синхронизироваться.
Для тех, кто предпочитает использовать Dropbox вместо bitbucket/github, вот что я делаю, чтобы избежать повреждения в процессе двусторонней синхронизации служб облачного резервного копирования:
Моя локальная папка с кодом c:\code & резервная папка c:\Dropbox, Внутри папки Dropbox у меня есть контейнер с зашифрованными файлами truecrypt (его размер достаточно больше, чем у моей папки с кодом). В течение дня я регулярно вносил изменения в мой локальный репозиторий Git/Mercurial. Однако в конце дня я закрываю Dropbox и монтирую контейнер с файлом truecrypt. Я помещаю изменения в пустой репозиторий в файловом контейнере, размонтирую его и перезапускаю Dropbox.
Таким образом, я могу безопасно использовать облачный сервис для резервного копирования моего хранилища DVCS. Если файловый контейнер используется, Dropbox будет ожидать его размонтирования, так что, надеюсь, изменений в нем нет. Тем не менее, если я получу конфликтующую копию контейнера файла, я легко смогу смонтировать обе копии и сравнить наборы изменений.
Я использую это с базаром в настоящее время через 3 машины. Тем не менее, я одинокий разработчик в любой из веток.
Я использовал команду init-repo --no-trees для создания хранилища.