Читая раздел для 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/
Относительно коммитов решил, что буду коммитить часто. Как ограничение "вечером не должно оставаться незакоммиченной работы".
Чтобы не зафлудить репозитарий сырым кодом буду применять следующее соглашение:
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/
Про бранчи vs клоны общий совет такой:
для собственных нужно лучше делать локально клоны.
Именованые бранчи для длительных линий разработки, типа есть три версии программы 1.0, 2.0, 3.0. Переход на новую версию стоит денег и не все пользователи переходят, сидят на 1.0 и 2.0, однако баги, возможно какие-то вкусняшки им давать необходимо (они купили). Дескать это хорошее применение для бранчей.
PS2:
Разумеется все теоретики запада против хранения генерируемых файлов в репозитарии - их можно моментально создать, любой версии, когда понадобятся (class, jar, war, ear, javadoc).
Сгенерированные исходники (Google Protobuf, из WSDL) - нельзя менять, но хранить в VCS можно. Для анализа, что менялось или "почему всё сломалось". Но менять нельзя!
Если в сгенерированные исходники надо внести изменения - советуют от них наследоваться, либо использовать композицию, тогда сгенерированный код может следовать за обновлениями, а не останется на века в той версии где подправили.
Сообщения
