Mercurial (и, я полагаю, Git) с Dropbox: есть ли недостатки?
У меня есть репозиторий Mercurial для личного проекта, и я храню главный репозиторий в моем Dropbox уже несколько недель (что-то вроде этой строки ]; и я понимаю, что это также возможно с git ).
Идея состоит в том, что он служит как способом работы с несколькими машинами, так и удаленным резервным копированием. Я клонирую репозиторий и работать с копией, отличной от Dropbox, и отправлять обновления только время от времени, точно так же, как я, я полагаю, работал бы с Bitbucket.
Можете ли вы подумать о каких-либо недостатках этой идеи по сравнению с использованием выделенного хостинга (BitBucket в случае Mercurial)? Я знаю, что Bitbucket имеет бесплатные учетные записи для одиночных пользователей, и это здорово, но они имитируется до 150M, что не так уж и много .
В частности, возможно ли, что процесс синхронизации Dropbox повредит репозиторий? Мне пришлось один раз запустить hg recovery в главном репозитории, но он мог быть не связанным (и в любом случае он благополучно восстановился). У кого-нибудь есть плохой опыт с этой идеей? Есть ли у кого-нибудь более длительный хороший опыт, который может облегчить мои беспокойства? Есть ли у кого-нибудь мнение, основанное на лучшем понимании внутренней сущности этих вещей?
edit: Я добавил некоторые пояснения к вопросам. Они выделены курсивом .
8 ответов
Я бы посоветовал не делать этого по причинам, указанным выше, но более настойчиво. Как mercurial, так и git имеют свои собственные протоколы для перемещения changesets между репозиториями. Эти протоколы оптимизированы/созданы для:
- эффективности
- согласованности (никогда не удаётся вытащить из репо в полуобновленном состоянии)
- хуки/триггеры -- делают что-то на push/pull, включая качественные (не разрешены табуляции и т.д.) фильтры
Когда вы просто позволяете каталогу синхронизироваться, вы можете управлять хранением . hg (или .git) в синхронизации, то во время этой синхронизации у вас есть удалённое хранилище, которое находится в непоследовательном состоянии и не знает его.
Кроме того, и hg и git разделяют то, что только локально, и то, что удалённо находится в состоянии диска. Они знают, какой информацией делиться (пример: коммитированные changesets), а какой нет (пример: текущая, локальная родительская ревизия рабочего каталога).
В других ответах люди говорят "скорее всего, всё будет хорошо" или "у меня никогда не было проблем", и это, скорее всего, правда, но это не гарантируется, и контроль ревизий - не то место, где можно проиграть шансы. Используйте правильный, лучший, безопасный, более эффективный, более полнофункциональный протокол синхронизации для вашей системы управления исходными текстами
.Я бы ожидал проблем, если бы вы попытались получить доступ к репозиторию в середине синхронизации. Также кажется, что это немного накладно. На самом деле вам не нужно синхронизироваться поверх того, что вы синхронизируете. Понятия не имею, как дропбокс справляется с конфликтами, но сомневаюсь, что он может сделать это в scm-aware способе.
Наверное, для личных проектов на одной или двух машинах это сработает нормально, но на самом деле вам захочется использовать профессиональный хостинг для многопользовательских проектов.
Я лично пользовался BitBucket некоторое время и был вполне доволен... вы можете иметь один частный проект и на бесплатном аккаунте.
.+1 для ведра. Это бесплатно, и вы получаете одно приватное репо с этой бесплатной учётной записью (в отличие от github).
Недостатком решения только с дропбоксом является то, что если вы что-нибудь испортите в репо на вашей машине, то эта ошибка будет скопирована в битбекет и реплицирована в любое другое место, где у вас установлен дропбокс. Деппбокс очень быстрый, так что вы не сможете вовремя остановить его, чтобы предотвратить проблемы.
Вы теряете возможность развязывать внесение изменений в ваш репозиторий с публикацией этих изменений.
Я действительно использую деппбокс для размещения пары репозиториев, которые я использую как на своих домашних, так и на рабочих машинах, но это не единственные копии этих репозиториев. Есть также битбеккет-репо (а также другие люди, у которых есть клоны этих репозиториев)
.Я использую Dropbox с git'ом для личных проектов уже довольно давно, и у меня пока не было ни одной проблемы. Хотя, бывают моменты, когда приходится ждать, пока Dropbox синхронизируется. Я думаю, что это может вызвать небольшие проблемы, если над одним и тем же проектом работает больше, чем несколько человек, но для личных проектов я считаю, что Dropbox даже лучше GitHub'а, хотя бы потому, что pushing/pulling быстрее.
Что касается pushing/pulling mid-sync, то, скорее всего, это вызовет проблемы, и может даже испортить ваше repo, но если вы единственный, кто работает над проектом, то вы точно знаете, когда Dropbox будет синхронизироваться.
.У меня были проблемы с повреждением моих репозиториев Dropbox. Это не происходит постоянно, но тот факт, что это происходило более одного раза, означает, что я собираюсь прекратить использовать Dropbox для этой цели.
Тем не менее, Dropbox, безусловно, дешевле, чем настоящий хостинг, поэтому, если вы храните резервные копии, вы можете найти его приемлемым для личных проектов.
Я бы не рекомендовал использовать Dropbox с mercurial, поскольку я часто вижу конфликтующие файлы между моим Mac и клиентами Windows. Особенно это касается отмены, но я также сталкивался с конфликтами с другими файлами.
С уважением Мирко
В настоящее время я использую его с Bazaar на 3 машинах. Однако я единственный разработчик в любой из ветвей.
Я использовал команду init-repo --no-tree для создания репозитория.