[cvs] Как убедить начальника?

> Если все разработчики "равны"

Такого не бывает - reviewer должен быть. А вот описанной тобой иерархии обычно нет.

> почему нельзя использовать единый репозиторий?

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

branchи и tagи дадут тебе больше геморроя, чем удобств.

> Такого не бывает - reviewer должен быть.
Это разница в подходах. В случае описанного мной выше примера с багзиллой reviewer выполняет "премодерацию", патч допиливается до тех пор, пока не достигает достаточной для коммита зрелости. Может быть и "постмодерация", когда все имеют право коммитить - тогда одно изменение может быть причиной нескольких коммитов (и тогда все равны). Обе модели жизнеспособны.

> Или ты согласен, что при итеративной разработки необходимо править коммиты, или нет.
Я нет. Я не делаю из коммита божество.

> reviewer выполняет "премодерацию", патч допиливается до тех пор, пока не достигает достаточной для коммита зрелости.

Представь, что допиливается серия патчей. Как разработчик справится без mq или подобного инструмента?

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

> Я нет.

Тогда ой.

> Представь, что допиливается серия патчей.
Для полноты картины (чтобы представить) - это серия независимых патчей, относящихся к совершенно разным частям и подсистемам проекта? Или это одно изменение, зачем-то разбитое на серию патчей?

> это одно изменение

Да

> зачем-то разбитое на серию патчей?

Есть куча хороших резонов это делать. Наипервейший - поиск ошибок.

> Есть куча хороших резонов это делать. Наипервейший - поиск ошибок.
Между патчами система должна быть в консистентном состоянии - или это необязательно?

>> Есть куча хороших резонов это делать. Наипервейший - поиск ошибок.

> Между патчами система должна быть в консистентном состоянии

Это требование к разбитой серии (мегапатч по определению переводит систему из одного консистентного состояния в другое, гг).

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

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

> Если нет требования консистентности между отдельными патчами

"Боже, храни мой английский^Wрусский" (c)

Да ланн, всего-то два родительных падежа подряд, бывает хуже%)

> Да ланн, всего-то два родительных падежа подряд,

Я не об этом. Мне казалось, что я ясно сказал: да, каждый патч оставляет систему в косистентном состоянии. Обычно :)

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

>> Я нет.

> Тогда ой.

Вообще это уже больше относится к качеству описания изменений в коде в процессе разработки.

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

DVCS уже позволяет разбивать толстые коммиты и фиксировать ход решения подзадачи. Т.е. изменения в коде получаются более мелкими и лучше описана история этих изменений в VCS. При этом получается локальная ветка с нестабильным кодом, которая постепенно доходит до стабильного состояния и уже затем проталкивается в основную.

PCS (вроде mercurial queues) позволяет не только разбивать толстые коммиты, но и исправлять ошибки в серии из мелких коммитов. Т.е. не загрязнять историю лишними коммитами, которые правят какие-то предыдущие локальные коммиты. Т.к. все это делается локально, то не хочется затем проталкивать такие коммиты с ошибками и их исправлениями в основную ветку. PCS как раз и позволяет фактически иметь локальные коммиты, которые можно еще и исправлять.

Вот как-то так мне это видится. С CVS/SVN такую гранулярность истории изменений кода, наверное, тоже можно поддерживать, но будет уже слишком сложно.

>Совершенно неочевидное утверждение (если мы говорим именно про PCS, не про VCS). Чем банальные атомарные коммиты (как это сделано в svn) не годятся? Чем там еще управлять? И чем в этом смысле любая DVCS принципиально лучше svn?

Иметь в истории один коммит на одну законченную (под)фичу очень полезно в условиях меняющихся требований. Удобно, когда для выбрасывания чего-то ненужного можно сделать hg backout и не лезть в код ручками вообще. А mq позволяет держать историю чистой.

> Мне казалось, что я ясно сказал
Ну значит, недостаточно ясно для тупого меня:)

Если каждый патч оставляет систему консистентной, я не вижу тонкой теологической разницы между патчем и коммитом. Мне кажется, это какое-то обожествление акта коммита и странноватый пуризм в отношении истории VCS...

Перефразируя известный слоган, commit often, commit early

> Удобно, когда для выбрасывания чего-то ненужного можно сделать hg backout и не лезть в код ручками вообще
В каком-то смысле да. Но в общем случае это невозможно - потому что на этот коммит уже могут быть наложены другие коммиты, и шанс, что придется все равно ручками ковыряться, очень большой.

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

> я не вижу тонкой теологической разницы между патчем и коммитом.

Теологически, коммит - это опубликованна неизменная часть истории проекта. Патч - это изменение в процессе разработки. Первое не редактируется никогда, второе предназначено для редактирования.

> commit often, commit early

...render your history useless. Хорошо согласуется с утверждением, что нужны не коммиты, а работающая система.

> это опубликованна неизменная часть истории проекта.
Ну Вы же понимаете, что неизменная она только до следующего коммита, затрагивающего этот же кусок кода.

>> коммит - это опубликованна неизменная часть истории проекта.

> Ну Вы же понимаете, что неизменная она только до следующего коммита, затрагивающего этот же кусок кода.

Ааааа держите меня трое!!!!!111 %)

Коммит - это ребро графа истории, вершинами которого являются версии дерева исходников. Новый коммит _никогда_ не меняет старый, он просто создает новую версию исходников (== вершин графа). А ты скоро договоришься, что вообще весь репозиторий - это один такой мутабельный коммит :D

Вопрос можно поставить по-другому: зачем вообще нужна VCS-история проекта?

> Коммит - это ребро графа истории, вершинами которого являются версии дерева исходников
Нет возражений.

> Новый коммит _никогда_ не меняет старый,
Перечитал те каменты. Да, возник мизандерстендинг. Конечно, коммит не меняется, меняется код. Но это никак не противоречит тому, что в коммите может быть ошибка (более того, никто не гарантирует от этого) и нужен другой коммит, чтоб ее пофиксить.

> зачем вообще нужна VCS-история проекта?
Чтоб знать, что где когда происходило, кто за это отвечает и т.д. АПВС?

>> зачем вообще нужна VCS-история проекта?

> Чтоб знать, что где когда происходило, кто за это отвечает и т.д. АПВС?

А... ну для распределения вины подойдет даже предельно замусоренная история. В ней даже интереснее копаться.

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

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

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

> типа поиска ошибок
????? Я думал, для этого люди используют unit tests/system tests/code reviews/... - и это на "фиксированном" коде, а не на истории.

> откат ненужного, перенос нужного
Мы же договорились, что патчи переводят систему из консистентного состояния в консистентное. В этом случае "патч=коммит" никак не мешает откату и переносу.

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

>> типа поиска ошибок

> ????? Я думал, для этого люди используют unit tests/system tests/code reviews/... - и это на "фиксированном" коде, а не на истории.

А по-моему, это обожествление unit tests/system tests/code reviews :D Ошибки пролезут через все тесты и ревью, причем это будут самы паршивые ошибки. И вот их придется искать бисектом или чем-то таким.

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

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

Такое мне попадалось, но это все равно надо код смотреть, а не только историю. Но не в этом суть. Я не очень понимаю, как "более мелкие" (или "менее божественные") коммиты мешают этому процессу.

> Я не очень понимаю, как "более мелкие" (или "менее божественные") коммиты мешают этому процессу.

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

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

> Самые паршивые ошибки придется искать дебаггером

Мне очень редко удается использовать для этого дебагер.

> курением логов

Логи? Какие логи? :)

> Ну... во всяком случае, мне не приходилось искать их медитированием над списком коммитов

Если есть сценарий воспроизведения, медитировать не надо - поиск является чисто механическим. Вводная обычно такая: "Сломалась фича X, которая работала в ревизии N - починить немедленно". Дифф между N и tip - километровый.

Ланн, мы тут уже давно кругами ходим, предлагаю закругляться. В среднем все поняли аргументы оппонентов, каждый остался при своем. Возможно, я слишком долго жил в мире cvs/patch/diff и мне везло с проектами...

>> А вот заведомо битые (те, для исправления которых делается еще один коммит) - мешают.

> Мне кажется, сильно меньше, чем введение и использование лишней сущности PCS

? PCS помогает сама по себе, в разработке. То, что получаются чистые коммиты и незамусоренная история - это полезный побочный эффект.