Mercurial - Hg

Начал читать http://hginit.com
Читая раздел для SVNщиков утер слезу - до чего верно пишет.

После этого полезно mercurial.selenic.com/guide


В UTF-8 не работает (глюк windows). Поэтому не chcp 65001 (меняет кодировку консоли на UTF-8), а chcp 1251 - ваш друг.
Для работы удобнее всего оказался cmd.exe /X /K chcp 1251 && cd "путь"

Отличная утилита HgWin, вызывается из командной строки (hgwin cmd) и открывает GUI окошко. Если сразу в GUI, то TortoiseHG вполне.

Отличная короткая статья об организации процесса подходящего и для моих проектов: http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/

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

1. закомичиваемый код должен компилироваться (этого можно достичь даже вечером, пустые методы с todo написать и тд)
2. если тесты не прошли или нет времени на все тесты, то commit message должен начинаться с "?": ?Обзвон нескольких телефонов в списке
3. если тесты проходят и по ощущениям код хороший, то commit message не начинается с ? и ! т.е. любые другие символы
4. если код отлично прошел тесты на DEV SERVER и его можно пытаться выкладывать на PRODUCTION, то commit message начинается с !
5. на бой выкладываются только ревизии с commit message начинающиеся на !
6. после выкладки на бой (вроде полетело, чуток поглядели - летит) тегируем версию "YYYY-MM-DD major.minor примечания"
7. после некого интервала (ничего не вылезло, клиенты не звонят с воплями) мержим default в stable

x. если вдруг потом обнаружен баг, переключаемся на "YYYY-MM-DD
major.minor примечания" в stable, правим / build, test, func/sys test, deploy / tag "ymd major.minor примечания"2, merge это исправление в default

y. если хочется надолго всё сломать - локальный feature clone. Из которого потом pull, merge в local#default и rm -rf feature clone


PS1:
Мучился вопросом: как бранчи случайно названные одинаково разными программистами не пересекаются?
Ответ: пересекаются! Рекомендуют именовать приватные бранчи "программист-название бранча".
http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less

Про бранчи vs клоны общий совет такой:
для собственных нужно лучше делать локально клоны.
Именованые бранчи для длительных линий разработки, типа есть три версии программы 1.0, 2.0, 3.0. Переход на новую версию стоит денег и не все пользователи переходят, сидят на 1.0 и 2.0, однако баги, возможно какие-то вкусняшки им давать необходимо (они купили). Дескать это хорошее применение для бранчей.


PS2:
Разумеется все теоретики запада против хранения генерируемых файлов в репозитарии - их можно моментально создать, любой версии, когда понадобятся (class, jar, war, ear, javadoc).
Сгенерированные исходники (Google Protobuf, из WSDL) - нельзя менять, но хранить в VCS можно. Для анализа, что менялось или "почему всё сломалось". Но менять нельзя!
Если в сгенерированные исходники надо внести изменения - советуют от них наследоваться, либо использовать композицию, тогда сгенерированный код может следовать за обновлениями, а не  останется на века в той версии где подправили.