DCVS как часто вы делаете commit?

Я как на SVN в своё время делал коммиты перед работой, так и на hg сейчас то же самое практикую.

Вот push/pull делаю реже. Периодически приходится конфликты расхлёбывать. Работаю с 4-6 мест с центральным репозиторием :)

Та же проблема.

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

прога запускается -> commit
большой кусок кода -> commit
багфикс -> commit

когда сам работаю -> коммит раз в 1-2 часа
на работе - некрофилия, как прихожу - cvs update, перед уходом - cvs commit


PS mercurial рулит!

s/cvs/svn/

s/mercurial/git/

За коммиты больших диффов с кучей семантически независимых изменений
следует отрывать яйца.

Иногда зарабатываешься и замечаешь, что дифф разросся и его можно
было бы порезать перед коммитом. Удобная рабочая среда помогает в
этом. В Emacs можно просматривать дифф одного файла или всего проекта
и удобно кромсать сам _патчик_, поэтому лишние изменения можно
отрезать и переместить в отдельный патч, потом закоммитить оставшееся,
потом закоммитить то, что было лишним.

И ещё. Большинство DVCS (Меркуриал точно умеет, гит, наверное, тоже)
умеют гонять произвольные хуки перед коммитом, прописываешь туда
коммит только при успешном `make check` и всё, enjoy your TDD: пока
тесты не пройдёшь — не закомитишь.

Силь распределённых систем контроля версий в том, что коммитить можно чаще без нареканий со стороны остальной команды. Всё равно потом мержить, но здесь хоть можно определить что и когда мержить, а не ругаться при каждом коммите с конфликтами, из-за того, что рабочий репозитарий один.

Когда фикшу баги - бывает и раз в 2-5 минут (вплоть до того, что в одной ветке один коммит).

Когда фичи делаю - от 20 минут до часу.

Причем если изменений слшком много - использую stage hunk - чтобы коммитить файлы по кусочкам.

а нельзя ли ссылку на то как разбить комит на несколько в Emacs?

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

// wbr

Для емакса есть пакет gitsum - см. http://xtalk.msk.su/~ott/ru/writings/emacs-vcs/EmacsGit.html#sec21

Самая простая и хорошая рекомендация (проверенная практикой): нужно коммитить не огромными пачками изменения, а меленькими. Тогда намного проще ориентироваться вообще, и, соответственно, писать лог.

+1

Если после изменений не сразу понятно, что же получается в diff, то надо разбивать и делать несколько коммитов. Ну и желательно, чтобы при коммите можно было все одной строкой описать.

Стараюсь делать почаще, один коммит на одно цельное изменение (будь то багфикс, новая фича или просто переформатирование кода), но постоянно срываюсь на большие коммиты :(

Пока не придумал, как себя перевоспитать...

> Самая простая и хорошая рекомендация (проверенная практикой): нужно коммитить не огромными пачками изменения, а меленькими. Тогда намного проще ориентироваться вообще, и, соответственно, писать лог.

отвлекаясь от конкретно DCVS - а мёржи бранчей? сделали бранч специально под какую-то новую фичу, мужики сидят, трудятся месяц и после мёржат его в хед. там в любом случае будет тааакой патч, что мама не горюй :)

я к тому, что конкретные количественные рекомендации в данном случае IMHO несколько надуманны, тк ситуации бывают разные, коллективы разные включая индивидуалов, да и сами по себе цели использования *VCS то-же могут быть разными. ну к примеру, есть проект, который пишется локально а вот собирается и тестируется удалённо. и VCS в данном случае - это может быть в первую очередь удобный инструмент для синхронизации дерева исходников, а логи все равно никто никогда реально читать не будет. всяко бывает.

// wbr

> я к тому, что конкретные количественные рекомендации в данном случае IMHO несколько надуманны, тк ситуации бывают разные, коллективы разные включая индивидуалов, да и сами по себе цели использования *VCS то-же могут быть разными.

Согласен. То была такая общая рекомендация. Конечно, все зависит от конкретной ситуации.

> отвлекаясь от конкретно DCVS - а мёржи бранчей?

А что с ними? Разве в нормальных VCS при этом не переносятся все патчи из одной ветки в другую (т.е. оригинальное деление на небольшие патчи сохраняется)? Или имеется в виду, что в таком случае специально все одним патчем переносят?

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

Как с этим в других DVCS?

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

> Как с этим в других DVCS?

с этим хорошо:

http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtension

или, если изменения не пересекаются в одних и тех же файлах, то можно коммиту указать файлы и каталоги, изменения в которых нужно зафиксировать.

Как показывает логика и практика (если разработчиков > 1), имеет смысл коммит делать тогда, когда решена определенная задача, будь то исправление ошибки в одной строчке или новая библиотека. Локально, пока изменения не готовы для переноса в публичную ветку, можно хоть как изгаляться - хоть через MQ, хоть через кучу мелких коммитов, которые затем объединить в один набор изменений (речь о mercurial). Через это имеем в публичных ветках логически чистую историю изменений. В чем сакральный смысл привязки изменений ко времени (коммиты каждые 2 часа, сутки и т.п)?

> постоянно ловлю себя на том что изменено очень много, и во время комита приходится сидеть и вспминать что же я поменял, и на сколько информативным должен быть лог? у меня git

Решение этих проблем - Mercurial с MQ. Хотя в Git тоже может быть что-то такое.

Я лично с недоумением вспоминаю SVN, где этого не было. Как это так - сделать коммит правильным и красивым с первого раза? %)

> Как показывает логика и практика (если разработчиков > 1), имеет смысл коммит делать тогда, когда решена определенная задача, будь то исправление ошибки в одной строчке или новая библиотека.

ну это конечно желательно. на самом деле, это и для 1го человека то-же верно. разве что VCS используется как rsync в сугубо автоматическом режиме.

> В чем сакральный смысл привязки изменений ко времени (коммиты каждые 2 часа, сутки и т.п)?

нету в этом никакого сокрального смысла :) ну разве что нет доверия своему рабочему месту и комит делается в первую очередь в целях бэкапа. но в бездумном режиме это все-таки зло и откатываться потом может быть оччень непросто.

// wbr

> Я лично с недоумением вспоминаю SVN, где этого не было. Как это так - сделать коммит правильным и красивым с первого раза? %)

ммм... по всей видимости, предложение "десять раз подумай и лишь потом закомить. чуть-чуть." не подходит? :)

// wbr

>> Я лично с недоумением вспоминаю SVN, где этого не было. Как это так - сделать коммит правильным и красивым с первого раза? %)

> ммм... по всей видимости, предложение "десять раз подумай и лишь потом закомить. чуть-чуть." не подходит? :)

Нет.

А как насчет выражения о вкусе устриц? ;)

> > Я лично с недоумением вспоминаю SVN, где этого не было. Как это так - сделать коммит правильным и красивым с первого раза? %)

> ммм... по всей видимости, предложение "десять раз подумай и лишь потом закомить. чуть-чуть." не подходит? :)

забыл подписаться:

// Ваш К. О.

А если серьезно, то ведь бывает, что логически целостное изменение занимает по времени не одну неделю и хорошо бы иметь инструмент для "отслеживания версий одного изменения" :) меркуриал (как наверное и некоторые другие) этот инструмент дает, а пользоваться им или - нет, тут уж каждый выбирает сам.

>А если серьезно, то ведь бывает, что логически целостное изменение занимает по времени не одну неделю и хорошо бы иметь инструмент для "отслеживания версий одного изменения" :) меркуриал (как наверное и некоторые другие) этот инструмент дает, а пользоваться им или - нет, тут уж каждый выбирает сам.

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

помоему сейчас логично всплывет вопрос о выборе системы контроля версий:) какие есть преимущества у разных систем?

> А если серьезно, то ведь бывает, что логически целостное изменение занимает по времени не одну неделю и хорошо бы иметь инструмент для "отслеживания версий одного изменения" :)

конечно, факт. а то и месяцев, если подсистема большая или это масштабный рефакторинг чего-то.

> меркуриал (как наверное и некоторые другие) этот инструмент дает, а пользоваться им или - нет, тут уж каждый выбирает сам.

ну с точки зрения cvs/svn на этот случай есть бранчи. завёл бранч в нём и играйся сколько хочешь. как закончили - смержили его в хед. пользоваться этой фичей или нет - это уже кому как нравится.

// wbr

> вы имеете ввиду разработка в отдельной ветке, с последующим мержем. или разбиение одного большого комита на несколько патчей?

Имею в виду, что локально неплохо иметь инструмент для отслеживания изменений по работе над какой-то задачей, которая в публичной ветке по частям появляться не должна, а только целиком, когда будет решена. Чтобы не засорять общую историю изменений ненужными локальными изысканиями. В меркуриале для этого можно использовать:

1) MQ - очередь патчей, которые накладываются на основной код. Когда задача решена, патчи объединяются в один набор изменений, который коммитится в основной код.

2) Коммитить промежуточные изменения тоже в основной код, а затем объединить их все в один набор изменений.

3) Оставить все как есть и лить все промежуточные изменения из локальной ветки в публичную, а там делать слияние (но только после того, как последнее изменение из локальной ветки дает требуемый результат). В этом случае получаем целостный проект только в точках слияния - тоже вариант, но некрасиво.

> 1) MQ - очередь патчей, которые накладываются на основной код. Когда задача решена, патчи объединяются в один набор изменений, который коммитится в основной код.

ммм... а разве "бранч" в понятии CVS/SVN - это не то же самое, что вы описали :-? или MQ имеет какие-то дополнительные фичи?

// wbr

> разве "бранч" в понятии CVS/SVN - это не то же самое, что вы описали :-?

Нет. Жалкое подобие :)

> или MQ имеет какие-то дополнительные фичи?

Да. Любой патч можно редактировать (ага, в SVN такое можно, при большом желании).

> Да. Любой патч можно редактировать (ага, в SVN такое можно, при большом желании).

простите конечно за чайниковский вопрос, но зачем может понадобиться *редактировать* патчи :-?

// wbr

> зачем может понадобиться *редактировать* патчи :-?

Ну типа разработка - итеративный процесс, не?

А вообще попробуй сам. Mercurial по первости в использовании не сложнее SVN, имеет инстрменты импорта SVN-репозиториев. Или можно сделать репозиторий из рабочей копии.

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

Но, по-моему, очень часто хочется вливать одну ветку в другую сохраняя исходное деление на патчи. А делать историю патчей красивой - тут и помогают всякие фишки типа редактирования патчей и проч.

> Ну типа разработка - итеративный процесс, не?

ну естественно итеративный, кто спорит. что-то придумал, написал локально, закомитил в бранч, тестеры подхватили и прогнали, найденные баги идентифицировали, исправил, закомитил в бранч. повторять до тех пор, пока состояние бранча не будет признано удовлетворительным, после чего замержить его в хед. причём совсем не факт, что конечный аккумулированный патч поступивший в хед будет выглядеть как-то по-особенному криво лишь от того, что в процессе итераций на изначальные патчи были наложены исправления посте тестирования. патч как патч.

> А вообще попробуй сам. Mercurial по первости в использовании не сложнее SVN, имеет инстрменты импорта SVN-репозиториев. Или можно сделать репозиторий из рабочей копии.

да мне пока что и CVSа хватает, куда уж мне до меркуриала :)

// wbr

> очень часто хочется вливать одну ветку в другую сохраняя исходное деление на патчи. А делать историю патчей красивой - тут и помогают всякие фишки типа редактирования патчей и проч.

Об этом и речь. Вливание одним большим патчем - это полный ахтунг, потом бисекцию хрен сделаешь, даже просто разобраться трудно. А так - история хоть и поддельная, но зато чистая :)

> что-то придумал, написал локально, закомитил в бранч, тестеры подхватили

Личный бранч и персональные тестеры? :) Ты по результатам тестирования делаешь новые changeset'ы, а мог бы править существующие - история чище и для бисекции удобнее.

> да мне пока что и CVSа хватает

ыыыы, ужоснахтунг O_o Я так и не смог себя заставить пользоваться CVS - он мешал больше, чем помогал.

> куда уж мне до меркуриала :)

Дело твое.

> Личный бранч и персональные тестеры? :)

ну что значит - личные? конечно не личный. общественные. есть development team, есть - QA. это разные человеки и задачи/инструментарий/etc у них тоже разные. если стоит у QA в планах тестирование такого то бранча - нет проблем, берут его и тестируют а найденные баги репортят в багзилу. что собственно удивительного в такой организации труда :-? это впрочем не означает, что девелоперы не тестируют свой код - конечно тестируют. но полноценные комплексные тесты системы - дело достаточно сложно и муторное -> есть отдельный тим.

> Ты по результатам тестирования делаешь новые changeset'ы, а мог бы править существующие - история чище и для бисекции удобнее.

ну это уже на самом деле IMHO мелочи. опять же, править живой код и вносить соотв. изменения в VCS чисто технологически наверное удобнее, чем поднимать патчи, искать в них что и как, править etc.

ps: а что такое "бисекция"? попытки протрассировать это слово по аналогиям завели в такие далёкие от vcs дебри...

// wbr

Вот никогда не понимал этой любви к переписыванию истории. Ещё и rebase придумали, еретики. По-моему, всё это происходит из подсознательной боязни сделать ошибку и нетерпимости к чужим ошибкам. Многие люди как усвоили от своих родителей и школьных учителей привычку чужие ошибки высмеивать, так и живут, других гнобят, сами боятся. А что такого, ну ошибся, следующим коммитом поправил. А чтоб ничего не ломалось, надо не палочную дисциплину наводить, а тесты человеческие писать. А история ошибок сама по себе ценна, помогает лучше понять ход мыслей разработчика, и даже если от каких-то идей в процессе разработки пришлось отказаться, в логах они всё равно останутся для истории, ничто не потеряно. А так человек месяц корпит-корпит, а в итоге получаются 5 тощеньких патчей, это почти такая же потеря информации, как и при случайных коммитах раз в неделю, лол.

> что такое "бисекция"?

Метод механического поиска изменения, внесшего ошибку - по сути, двоичный поиск на графе ревизий. Автоматизирован в приличных DVCS, но полагается на то, что все вершины графа являются вполне работоспособными.

http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension

> а что такое "бисекция"?

Думаю, tailgunner имеет в виду поиск проблемных патчей путем деления истории пополам. Я бы сказал шире - перенос истории изменений при слиянии веток упрощает задачи анализа изменений через некоторый период времени.

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

Но так бывает редко. Это еще, конечно, вопрос интерпретации понятия "атомарная". Для кого-то новая кнопочка - отдельная фишка, а для кого-то таковой является целая подсистема.

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

Кстати, неужели удобно пользоваться CVS, который с отдельными файлами работает? Лично для меня переход CVS -> SVN был гораздо более эйфоричным, нежели переход SVN -> darcs, именно по причине атомарных изменений на уровне нескольких файлов в SVN.

С CVS-ом приходилось всякие перловки писать для банального анализа истории.

> никогда не понимал этой любви к переписыванию истории. Ещё и rebase придумали, еретики.

На костер отступников! :)

> По-моему, всё это происходит из подсознательной боязни сделать ошибку и нетерпимости к чужим ошибкам.

Это происходит из нескольких простых наблюдений: рулят относительно небольшие изменения в транзакционном стиле; ошибки неизбежны; многие ошибки вылезают довольно быстро после коммита.

> ну ошибся, следующим коммитом поправил.

Ну два коммита вместо одного, граф ревизий в два раза раздулся - какая фигня :)

> история ошибок сама по себе ценна, помогает лучше понять ход мыслей разработчика, и даже если от каких-то идей в процессе разработки пришлось отказаться, в логах они всё равно останутся для истории,

В общем-то да, но 1) ты же сам выбираешь, что убрать, а что оставить 2) кроме логов VCS есть еще (теоретически, по крайней мере) Вики и багтрекер.

> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension

фича конечно интересная, но, боюсь, далеко не всегда применимая на практике. проблема в том, что далеко не так просто идентифицировать версию, в которой точно нет такого-то бага. особенно если это скрытый рейс, который проявляется при весьма специфическом стечении обстоятельств и с бОльшей вероятностью прошёл штатные тесты системы [запросто. они то-же не идеальны.]. по крайней мере по своей практике могу лишь сказать, что проблемы, которые действительно можно было назвать гордым словом Баг [а не банальный хорошо трассируемый SIGSEGV] и на который даже на просто точную идентификацию и повторяемость могли уходить недели, обычно всплывал неожиданно, рождался когда-то давным-давно не совсем непонятно кем и мог жить долго-долго. просто сегодня вот так сошлись звёзды, что всё упало. наконец то.

впрочем, не спорю с тем, что где-то бисекция может быть полезной.

// wbr

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

Но это надо не просто отметки и поиск по ним (как в darcs, скажем), но еще и автоматическую группировку пометок, чтобы было удобно на любом уровне такой многоуровневой истории работать с патчами.

И этот подход требует либо возможности редактировать патчи, либо могучего продумывания системы пометок заранее и железного следования придуманному по ходу разработки.

>> http://www.selenic.com/mercurial/wiki/index.cgi/BisectExtension

> фича конечно интересная, но, боюсь, далеко не всегда применимая на практике. проблема в том

Блин, да понятно это всё. Но никто не обещал серебряной пули.

> скрытый рейс, который проявляется при весьма специфическом стечении обстоятельств

Практически всегда перед тем, как исправить ошибку, ее приходится воспроизвести.

> где-то бисекция может быть полезной.

Ога, даже беглое чтение lkml это доказывает :D

> Вот никогда не понимал этой любви к переписыванию истории. Ещё и rebase придумали, еретики.

Это не для переписывания истории, а для избавления от излишнего ветвления. Mercurial (как и другие DVCS, наверное) обладает свойством таким - ветвление на каждом шагу. Pull изменений, работа недельку, коммит и вот уже имеем ветку которую надо мержить, а во многих случаях оно по сути и не ветка вовсе, так как мои изменения не пересекаются с теми что были между двумя этими pull'ами. И rebase как раз помогает сделать это не веткой а просто очередным коммитом.

И усилий никаких не требует:

hg pull; hack ...;hg ci;hg pull;hg rebase

вуаля

Тем не менее, большая часть ошибок - банальны и отыскиваются по истории изменений. И очень удобно, если такие неинтересные ошибки можно локализовывать автоматически.

Ничего плохого в ветвлении я не вижу. Мёржей боятся те, кто слишком долго сидел на CVS/SVN. Конкретно к rebase претензии такие: в отличие от merge, он изменяет старые ревизии, хотя вся удалённая работа основана на их иммутабельности. Поэтому делать его можно только в локальной ветке, которую ты никогда никому не показывал.

А история мёржей, что мне нравится, показывает, как оно было на самом деле, безо всякой показухи. Смотришь на граф ревизий, и все проблемы координации разработки сразу как на ладони.

> да мне пока что и CVSа хватает, куда уж мне до меркуриала :)

с содроганием вспоминаю времена, когда работали под CVS. Отсутствие атомарных коммитов - вообще жопа. Как-то так хватило нам смелости сделать кардинальный шаг - перелезли с цвса сразу на Mercurial. Самая главная сложность была - не освоение mercurial, нет. А разработка четкой, по возможности простой методики работы, которой бы все следовали. В CVS с этим проще - hg co, hg ci, все по сути. Рассматривали как вариант SVN, но Mercurial лучше подошел в силу нескольких важных причин.

"Попробуй - полюбишь" :) Он прост, проще некуда. Впрочем, если все устраивает в CVS'е, то зачем я все это говорю :)

собсно, речь и была про локальную ветку