Как синхронизировать репозиторий через облачные хранилища (Google Drive, Dropbox, etc)?

Question

[KerVitarLaeda]

Один разработчик использует несколько машин. Переходя от одной к другой нужно иметь актуальный рабочий каталог проекта. Проект содержится в репозитории (hg, но актуально для любой vcs). Коммитить в удаленный репозиторий чтобы просто перейти на другую машину неудобно. Хочется просто сесть и продолжить работу.
Кажется, что можно просто положить проект в любой облачный диск (Google drive, dropbox, etc) и проблема решена. Но я слышал что в таком сценарии hg начинает глючить из-за влияния неконтролируемой им синхронизации служебных файлов репозитория. Коллега использует этот сценарий и иногда репозиторий зависает с непонятными ошибками.
Можно исключить из синхронизации через облако саму папку с репозитарием .hg и синхронизировать только рабочий каталог. Но есть проблема:
* делаем несколько новых коммитов, публикуем в "главный" репозиторий
* делаем еще изменения в рабочем каталоге,
* переходим на другую машину
* рабочий каталог репозитория уже обновлен - все изменения присутствуют
* стягиваем новые коммиты из "главного" репозитория
Как теперь объяснить репозиторию, что в рабочем каталоге уже актуальная версия на "вот этот коммит" + еще какие-то незафиксированные изменения???
Если просто сделать update, то потеряем незафиксированные изменения.
Возможно я не знаю банальной команды hg.
Возможно нужно как-то правильно "готовить" hg в связке с облачной синхронизацией.
Поделитесь пожалуйста своим решением проблемы.

Comments

[KerVitarLaeda]

Nikolay Petyukh, запушить - не проблема, но я не хочу в репозитории коммиты вида "еще некоторые изменения".
Коммит должен содержать атомарный и осмысленный набор изменений. Т.е. я делаю коммиты когда готов к этому, а не когда мне вдруг приспичило это сделать.

Answer 1

[GavriKos]

Правильный ответ - никак. Синхронизируйте репозиторий через удаленный сервер с этим самым репозиторием. И не изобретайте себе геммороя.

Answer 2

[spaceatmoon]

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

Как теперь объяснить репозиторию, что в рабочем каталоге уже актуальная версия на "вот этот коммит" + еще какие-то незафиксированные изменения???

git fetch

Смотри сейчас тебе батька покажет тайную технику использования гита.
1. git fetch
2. git pull
3. git push

Comments

[KerVitarLaeda]

Спасибо, Капитан!

[spaceatmoon]

KerVitarLaeda, всегда рад помочь!

Answer 3

[Сергей Кузнецов]

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

Разница идеологий. Если Git это инструмент, помогающий создавать качественный код, то Mercurial является лишь инструментом фиксации уже готовой работы и эту самую работу над кодом лишь усложняет. А если какой-то мусор попал в репозиторий, то это навечно. Придётся смириться со случайно закоммиченным тяжелым файлом и заставить скачивать его всем коллегам, так как история «священна» и не подлежит переписыванию.

Answer 4

[Армянское Радио]

Учитывая, что при каждом коммите папку с БД репозитория знатно переколбашивает, вы рискуете тратить десятки минут на синхронизацию средствами облачных дисков, в то время как отправка диффов при синхронизации с репой займет секунды.

Answer 5

[tikhenko]

Следует разграничить каталог исходников и каталог репозитория.
Каталог исходников держим в Dropbox. Каталог репозитория на каждой машине создаем вне Dropbox-а, внутрь кладем символическую ссылку на каталог исходников (на винде это mklink /j).
Например:

cd my_repo
mklink /j src /path/to/Dropbox/my_src

Каталог исходников автоматически синхронизируется на каждой машине, коммитим из каталога репозитория.