Ответ 1
Вот ваши индивидуальные вопросы, по одному разделу, с моим мнением/ответом на каждый.
7. Когда я готов и готов, я иду Sync- > Push (Итак, все это хорошо?
Правильно.
Единственное, что может отличаться в этом рабочем процессе, - это то, что есть кто-то другой, который также нажимает на тот же репозиторий. Если у вас это есть, в какой-то момент кто-то еще нажал на набор изменений в репозиторий, который у вас локально отсутствует. Когда вы пытаетесь подтолкнуть свое, что создало бы ветку в онлайн-репозитории, сделанное видимым несколькими "головами" (вы должны искать этот термин в контексте Mercurial, если вы не понимаете, что я имею в виду.) Как правило, t, чтобы это произошло, поэтому нажатие будет прервано.
Когда он прерывается, вместо этого вы вытаскиваете набор изменений из онлайн-репозитория вниз в свой локальный, объедините свою голову с головкой, которую только что вытащили, а затем повторите попытку, которая обычно будет успешной (если только вам не повезло и кто-то еще толкнул больше тем временем.)
Что касается файлов HgSCC и Add, у меня были проблемы с HgSCC, поэтому я переключился на VisualHg - http://visualhg.codeplex.com, в частности, потому что там что-то не так с версией H2SCC версии 1.52 относительно новых файлов. Если вы не можете найти решение для этого, я бы предложил вам попробовать VisualHG.
Вы забыли слиться?
Вы должны объединить свои изменения вместе, чтобы у вас была только одна голова. У вас есть 3 в этом примере скриншота, "добавлена кнопка для формирования 2", "final commit" и "2nd prj (2)". Вы должны обновить до того, который вы считаете "большей частью своего проекта", выберите его, затем щелкните правой кнопкой мыши на одной из других головок и выберите "Слить с..." в TortoiseHg и выполните слияние и фиксацию. Каждое такое слияние + фиксация удаляет 1 головку, поэтому вам нужно как минимум 2 таких слияния, чтобы вернуться к 1 головке.
У Kiln и Fogcreek есть другое понятие о том, как обращаться с ветвями, чем у многих других. Они предлагают вам создать совершенно другой репозиторий веток и работать в нем вместо использования названных ветвей. Именованная ветка будет сродни тому, что вы назовете три набора изменений на скриншоте (3, которые заканчиваются на "final commit" ) в качестве ветки для добавления новой формы или исправления большой ошибки.
Таким образом, вместо того, чтобы делать то, что вы здесь сделали, имея 3 головы, "путь" "Кинн" должен состоять в том, чтобы иметь 3 клона, каждый с только наборами изменений до своей ветки. В принципе, у вас было бы 1 репо-клон со всем до "добавленной 2-й формы" и продолжением "второго proj", но изменений между ними не было. Второй клон имел бы "добавленную 2-ю форму", а затем одну дополнительную помеченную "добавленную кнопку для формирования", а третья имела бы "добавленную вторую форму", а затем три окончания с "окончательным фиксацией".
Конечно, в конце концов, при нажатии и вытягивании, чтобы вернуться в основной репозиторий, вы все равно окажетесь с этими ветвями, но они рекомендуют использовать репозитории веток, подобные этим для больших веток, такие как добавление больших функций, модулей, и др.
Я предполагаю, что mercurial обрабатывает слияние самостоятельно?
Слияние в вашем сценарии вступит в игру только в том случае, если у вас есть новые изменения как в исходном репозитории, так и в вашем клоне репозитория ветки.
Если у вас это есть, нажатие из репозитория ветки в исходный репозиторий (или потянув другой путь) добавит новые главы в ваш целевой репозиторий. Это то, что слияние поможет вам избежать.
Таким образом, ваш рабочий процесс будет выглядеть следующим образом:
- Нажмите все изменения, которые у вас есть в репозитории веток (т.е. изменения, вызванные тем, что вам нужен репозиторий веток, в первую очередь, большой багфикс, новая функция, большая перезапись, что угодно)
- Попробуйте нажать из репозитория ветки в исходный репозиторий, получив сообщение о том, что это создаст главы в целевом репозитории, поэтому вы прервите это.
- Извлеките исходный репозиторий в репозиторий веток. Это создаст другие главы.
- Вытащите из репозитория веток в локальный репозиторий и выполните слияние здесь, обрабатывая любые конфликты слияния и, наконец, совершая изменения в слиянии.
- Нажмите из локального репозитория обратно в репозиторий веток
- Завершите любые просмотры кода, которые вы, возможно, захотите сделать в Kiln, прежде чем сделать официальным
- Нажмите из репозитория ветки в исходный репозиторий (обратите внимание, что это то же самое, что и на шаге 2, если кто-то еще (или вы) сделал больше работы в исходном хранилище, тем временем, вернитесь к шагу 3 и повторите)
разница между параметрами журнала просмотра и просмотра изменений
Разница заключается только в том, что вы просматриваете. История просмотров всегда показывает историю для того, что вы выбрали, будь то файл или файл решения, т.е. просто изменения, связанные с этим файлом.
View Changelog просматривает журнал изменений для репозитория, независимо от того, что вы выбрали.