Используя Mercurial, есть ли способ быстрого резервного копирования в хранилище tmp? - PullRequest
1 голос
/ 19 июня 2010

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

Так что на самом деле у меня есть хранилище tmp на нашей главнойсерверный компьютер, и я могу hg push к нему.Дилемма в том, что я не могу нажать, пока я не сделаю коммит сначала, и из предыдущего опыта мы не должны делать коммиты, если мы не готовы нажать на центральный сервер (чтобы поделиться кодом с коллегами, объединить и т. Д.) (Причина в том,мы не можем выдвинуть выбранные файлы - мы должны подтолкнуть все зафиксированные файлы или ничего не выдвигать).Итак, как решить эту проблему?

Есть ли способ сказать «скопировать все ИЗМЕНЕННЫЕ ФАЙЛЫ (и добавленные файлы) в / user / peter / 2010-06-18 на центральном сервере?)» Или не фиксироватьно каким-то образом получить его на сервер?

1 Ответ

4 голосов
/ 19 июня 2010

Обычный способ - просто зафиксировать. При использовании DVCS настоятельно рекомендуется «делать коммиты рано, делать часто». Часто выполняйте локальные коммиты, а затем в целях резервного копирования часто нажимайте на tmp repo на сервере. Когда вы довольны своей работой, вы переходите с репозитория tmp на общий «центральный» сервер.

Нет необходимости следить за тем, чтобы все компилировалось после каждого набора изменений, норма состоит в том, чтобы просто убедиться, что каждая задняя часть набора изменений, которую вы нажимаете, оставляет «подсказку» в состоянии компиляции. Обычно сервер триггеров непрерывной интеграции запускает сборку после прибытия каждой группы наборов изменений (changegroup) и учитывает только «подсказку».

Если вы действительно, действительно не можете терпеть наличие наборов изменений, которые не могут существовать самостоятельно, то Mercurial Pro будет использовать Mercurial Queues , чтобы держать версионный патч в отдельном хранилище очереди во время работы в теме. Кто-то, кто хочет играть с огнем, использовал бы расширение коллапса, чтобы объединить последовательность наборов изменений в один набор изменений перед отправкой в ​​общие репозитории.

Из трех представленных вариантов:

  1. исправьте ваш рабочий процесс, чтобы центральное хранилище могло обрабатывать наборы изменений, которые не компилируются, если они являются частью группы изменений, которая компилирует
  2. использовать ртутные очереди для хранения патча в хранилище исправленных версий
  3. использовать расширение коллапса, чтобы переписать историю (игра с огнем)

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

...