Перемещение неполного кода между ртутными проверками

Question

Я проверил кодовую базу на своем настольном компьютере и поработал над ней. Теперь я ухожу и хочу эти изменения на моем ноутбуке.

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

Какой лучший способ справиться с этим? Создать и применить патч? Использование hg служат для перемещения незавершенных изменений?

Answer 1

Вот три способа сделать это. Я расскажу о плюсах и минусах каждого:

Опция 1 : используйте hg diff, чтобы получить файл сравнения, показывающий незафиксированные изменения, а затем hg import --nocommit на принимающей стороне, чтобы применить эти изменения без создания нового набора изменений

• Плюсы : просто, не создает наборов изменений
• Минусы : на самом деле не использует Mercurial, то есть DVCS. Может не поймать вновь добавленные файлы

Вариант 2 : фиксация на отправляющей стороне, подтолкнуть к принимающей стороне (или вытащить с нее, или положить hg bundle на флэш-диск), минуя рабочий сервер, update в принимающая сторона, а затем hg rollback на обеих сторонах, чтобы исключить набор изменений (но оставить изменения.

• Плюсы : Использование push и pull для перемещения по изменениям, аналогичным намерениям ртути
• Минусы : Хаки. Полагается на откат, который работает только на 1 уровне. Случайно потяните дважды, и вы не можете отменить первый.

Опция 3 : Фиксация на отправляющей стороне. Нажмите на репозиторий для разработчиков, к которому у вас есть доступ, и Потяните на принимающей стороне. Не подталкивайте к репо компании до тех пор, пока все не будет создано, но когда вы толкаете, толкайте все промежуточные наборы изменений

• Плюсы : Точно, о чем DVCS. Ваш заказ на работу задокументирован и сохранен
• Минусы : требуется настроить клон только для вас

FWIW, я рекомендую вариант 3. Репозитории для разработчиков - это именно то, о чем говорят DVCS. Если вашей компании нелегко установить его на сервере, к которому вы можете получить доступ из дома и за его пределами, отметьте для них огромное значение, документировав процесс, приведший разработчика к завершенному исправлению / функции , и то, что поощрение разработчиков часто переходить к репо, не требующему компиляции, хорошо для ежедневного резервного копирования.

Наконец, после того, как вы закончили с вашей функцией или исправлением, вы всегда можете свернуть все промежуточные наборы изменений. Мне не нравится это делать (я показываю вашу работу такой парень), но вот как: Могу ли я раздавить коммиты в Mercurial?

Answer 2

Хмм .... если вы хотите, чтобы "голова" была чистой, тогда (и я могу не получить правильных терминов для Hg, я думаю, что в SVN еще недостаточно сделано Hg):

Ветка перед вашим текущим циклом изменений, настройкой текущей работы, то есть того, что не собирается, быть в ветке, зафиксировать изменения в ветке, перенести ветку на ноутбук, иди, играй, возвращайся затем объедините все это вместе (что должно быть довольно тривиально, так как голова не изменится) и обрежьте ветвь, если вы действительно этого хотите!

Я видел вариации этого написанного «мимоходом» несколько раз - всегда считалось причиной того, что DVCS «лучше», хотя мне, вероятно, понадобится остаток дня, чтобы найти вам пример) -:

В качестве альтернативы (немного подумав - и позволяя использовать SVN гораздо больше) - ключом будет то, что я смогу зафиксировать в своем локальном репозитории «WIP» все, что захочу, сломанный код или нет, и, следовательно, будет тянуть (или подтолкнуть ) мой текущий WIP к ноутбуку и обратно благополучно. Хранилище, которое должно быть чистым (чтобы всегда создавать), является «серверным», поэтому, хотя я могу фиксировать локально, я бы не стал PUSH в этом хранилище - серверном - пока все не будет хорошо ... (тогда этот «серверный» репозиторий будет тем, который запускает сервер сборки и т. д.). Я подозреваю, что это последнее ближе к большинству описанных мною примеров.

Answer 3

Это может показаться некультурным, но я часто использую rsync для перемещения «находящихся в процессе» хранилищ по SSH, пока не доберусь до точки, где есть что-то стоящее.

Answer 4

Еще один крутой вариант (но немного более сложный) - поместить незавершенные изменения в MQ (сначала включите расширение mq) и создать версию mq (qinit -c). Затем используйте qcommit, чтобы зафиксировать текущее состояние очереди исправлений и синхронизировать вашу незаконченную работу, потянув и нажав mq.