2011-03-22

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 можно. Для анализа, что менялось или "почему всё сломалось". Но менять нельзя!
Если в сгенерированные исходники надо внести изменения - советуют от них наследоваться, либо использовать композицию, тогда сгенерированный код может следовать за обновлениями, а не  останется на века в той версии где подправили.

7 комментариев:

Dmitry Sukhovilin комментирует...

Мучаюсь вопросом: Со временем, репозиторий может вырости до неприлично больших размеров. Как делать hg clone при размере в несколько гигов....

Unknown комментирует...

Я не настоящий сварщик, поэтому только предположения:

- несколько гигов это круто. Сейчас померил сколько весит на диске Vaadin (без истории, но с jar-никами) 108 МБ

- уверяют, что HG делает хардлинки и новый (разумеется локально) и клон будет крохотный.

Вы ведь под Linux - проверьте, и поделитесь потом знанием?

Dmitry Sukhovilin комментирует...

$ hg version
Mercurial Distributed SCM (version 1.6.4)

$ hg clone test test1

$ ls -i говорит, что inode разные :(

P.S. test and test1 локальные.

Unknown комментирует...

1.8.3 на дворе ;-)

ls -i показывает inode test test1?
Тут к бабушке не ходи - разный.
Скорее всего _некоторые_ файлы в .hg dir хардлинки.

Рекомендую почитать у них на сайте.
Я даже книжку не прочитал ;-)

Но после перехода с SVN на HG папки полегчали: там с одной стороны появилась вся история в .hg, но с другой убились дубли в .svn и в итоге оказалось, что svn без истории занимал больше.

Насколько я знаю официально признается, что активная работа с binary файлами это лучше у svn.
DVCS само собой будут разбухать у всех участников.

Git говорят более прожорлив к месту и требует "дефрагментации", но весь линукс в нем держат ;-)

Dmitry Sukhovilin комментирует...

ls -i делал для 2-х .java фалов проекта.
Для binary сделали отдельный репозиторий.

Unknown комментирует...

Эээ! Хардлинки спец файлов внутри репозитария!

А не для файлов пользователя.
Файлы вне .hg вообще можно удалить.
Он их из репозитария (папка .hg) может восстановить.

Dmitry Sukhovilin комментирует...

Да, системные файлы клона это хардлинки.