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

К вопросу о ловле неустойчивых сбоев bisect'ом: http://lwn.net/Articles/304105/

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

из реальных претензий к CVS, которые технически меня напрягали, могу вспомнить лишь одну: *дикие* тормоза при простановке тэга на большом проекте [десятки тысяч файлов]. особенно, если сервер удалённый и связь есть, но не как в локалке. можно было запустить cvs tag и смело идти домой бо проставится лишь через пару-тройку часов при условии, что всё ок. как следствие, каждый раз мутотень с заведением бранчей. это действительно напрягало в момент бранчевания. всё остальное типа отсутствия rename - это в принципе технологические мелочи, с которыми вполне можно нормально жить не особо напрягаясь. по крайней мере, они не доставляли столь больших проблем, чтобы переход с CVSа на что-то ещё был бы рационален.

// wbr

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

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

Ветки в DVCS сами по себе образуются - клонировал репозиторий, внес изменения зафиксировал и в общем случае получил ветку.

Но там есть именованные ветки, только не возникало нужды ими пользоваться.

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

а потом если кто-то другой обновится на эту "промежуточную" ревизию с ошибкой, у него может не собраться. (стандартная ошибка: "текущая версия из SVN не собирается"). Хотя это всё решается тегами: если протестировано, метится как LKG, и при обновлении берутся только LKG ревизии. Хотя в крайнем случае, обновляющийся может поискать бисекцией LKG версию вручную, или если в head только LKG, а девелопер с ошибками резвится в своём отдельном бранче, это и так автоматически получится.

> Автоматизирован в приличных DVCS, но полагается на то, что все вершины графа являются вполне работоспособными.

фактически, ты сам помечаешь с помощью good/bad, что работоспособно, а что -- нет. А DVCS просто автоматизирует поиск по помеченным узлам.

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

неудобно, ага. В CVS приходилось делать много лишних тегов на атомарные фичи, вроде очередного релиза или подсистемы.

> 2) кроме логов VCS есть еще (теоретически, по крайней мере) Вики и багтрекер.

для одного-двух человек их можно держать в отдельных файлах в том же репозитории. Тогда автоматически вики и багтрекер получают ссылки на ченджсеты. А "ход мысли разработчика" лучше озвучить явно в отдельном файле той же вики. Начали реализовывать подсистему -- записали в вики план, сгенерировали из него TODO list, сделали/протестировали -- пометили TODO [DONE], решили всё переделать -- написали тесты, очередной план разработки, переделали, пометили и т.п. История "хода мысли", если нужна, достаётся из вики.

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

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