subversion 1.5.0

Основное отличие нормальных vcs с атомарными комитами - в том что можно понять что происходит с исходниками - посмотрите например сюда- http://www.selenic.com/hg/ (здесь живут исходники mercurial). Каждый комит имеет описание и список файлов (измененных, добавленных, удаленных, переименованных). vcs с пофайловыми комитами в плане удобства совсем недалеко ушли от сетевой шары (причем имхо cvs немного лучше чем шара, а clearcase - хуже).

Еще есть такие "мелочи" как целостность репозитория. В cvs/clearcase можно запросто закомитить только половину изменений, потом что-то обламывается и вуаля - в репозитории нежат некомпиляющиеся сорцы. В тех-же svn/hg так не бывает.

Вообще достаточно недельку плотно поработать с нормальным репозиторием и потом на cvs/clearcase смотреть будет в лучшем случае неприятно. С другой стороны если все равно и дальше придется жить с clearcase то лучше не смотреть. Знать что весь мир пользуется теплыми туалетами и продолжать ходить зимой по нужде в ямку на улицу крайне неприятно.

С checkout похожая история. Да, им можно пользоваться, то только когда изменения вносятся раз в месяц, общее кол-во пользователей репозитория <= 5 и сидят они в одной комнате. Если девелоперов хотя-бы 10 - то крайне желателен плагин к ide которые этот checkout делают. А теперь сделайте какой-нибудь толстый рефакторинг, причем без плагина так как плагин делает reserved checkout после которого девелоперам в сингапуре резко плохеет. Желательно чтобы рефакторинг делали сразу 2 человека.

Вообще-то писать можно много - но мне лень. Уже 10 лет назад все давно поняли что хорошо и что плохо и в инете наверняка масса статей на эту тему. Сейчас еще спорят про Centralized VCS vs DVCS а про системы с неатомарными комитами и чекаутами давно все забыли. И только корпоративные пользователи вынуждены заниматься некрофилией. Но насиловать трупы не всем по душе, хоть иногда и приходится :(

(пояснения для предыдущего анонимуса)

>Каждый комит имеет описание и список файлов (измененных, добавленных, удаленных, переименованных)

то бишь, changeset -- связанное изменение нескольких файлов за один коммит.

>vcs с пофайловыми комитами в плане удобства совсем недалеко ушли от сетевой шары

отчасти эти changesetы можно эмулировать множеством тегов на каждый чих. Правда, в отсутствие атомарности этот костыль будет работать ненадёжно.

> В cvs/clearcase можно запросто закомитить только половину изменений, потом что-то обламывается и вуаля - в репозитории нежат некомпиляющиеся сорцы. В тех-же svn/hg так не бывает.

а вот это собственно "атомарность" коммитов. В смысле транзакции, либо коммит фиксируется целиком для всех файлов, либо не фиксируется вообще.

> 6. Тут тоже не могу ничего сказать ибо даже в дурном сне мне не придет в голову получить ВСЕ исходники. И главное зачем?

например, сделать feature branch. Ветку на одну фичу, поэкспериментировать, набросать прототип. Если фича понравится, подгрузить обратно в ствол.

В dvcs ветки (и главное, потом merging) делать гораздо проще, поэтому этим хочется пользоваться постоянно.

Или по ветке на разработчика: оба работают над одной мегафичей, но первому ещё захотелось поэкспериментировать над другой. Тогда у второго должна быть отдельная ветка, со "ВСЕМИ исходниками".

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

>2. На мой взгляд это наоборот достоинство. Чтобы положить в холодильник жирафа необходимо сперва открыть холодильник.

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

Пример:

1) Я делаю какие-то существенные изменения в коде

2) Кто-то другой также делает существенные изменения и коммитит.

3) На этот момент у меня локально — полностью рабочая версия. Всё компилируется, тесты проходят. Но закоммитить я её не могу.

4) Делаю апдейт... Вротмненоги! Куча конфликтов, надо садиться и исправлять весь код. И откатиться уже нельзя! При этом заметь, эти изменения будут каша из новой фичи из пункта 1 и собственно результат мерджа. Т.е потом по истории будет сложно понять, что есть результат новой фичи, а что — механический мердж.

В случае с Mercurial ситуация выглядит так:

1) Я делаю какие-то существенные изменения в коде

2) Кто-то другой также делает существенные изменения и коммитит.

3) На этот момент у меня локально — полностью рабочая версия. Всё компилируется, тесты проходят. Спокойно комичу код.

4) Получаю в репозитории две "головы". Сажусь и спокойно их мерджу. В случае чего всегда могу откатиться — фича из пункта 1 уже зафиксирована в репозитории.

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

Целостность. Да. Совершенно верно в СС можно залить только половину изменений. Но ничего страшного не произойдет ибо лежать это добро будет на девелоперском бранче и при интеграции на мэйнбранч дельту ломающую билд СМ инженер выкинет нафик.

В свн мне столь же непринужденно девелоперы заливали битую дельту. Так что технически это тоже возможно :) Кривые руки не победить ничем :)

Чекаут. Из личного опыта. Ежедневная интеграция 2-3 десятков файлов, с конфликтами в среднем 10. Авторы сидят в разных концах мира, и половина из их индусы и китайцы (кто знаком с привычкой данных категорий к порядку те поймут). Никаких проблем интеграция не доставляет как правило. И заметьте никакой GUI, все делается в терминале. Кроме сложных мержей, тогда GUI и тут тупняк.

Для нелюбителей co есть findmerge. Сi он правда не отменяет.

Повторяю. Инструмент очень богатый. Избыточно даже я бы сказал. Промышленная такая хрень.

Минус реально 3. 1. Цена. 2. Тяжеловесность. 3. Некая архаичность (чем то мне в этом напоминает Unix'ы)

Можно критиковать, можно не одобрять то как он работает. Но говорить что он какашка это неправильно.

Вот как бы и все что я хотел донести :)

Я понял. Не уверен правда в такой уж крайней необходимости атомарных коммитов. Буду думать.

Вы в корне не правы. Ему совершенно не нужны ВСЕ исходники. Ему нужен бранч с измененными им элементами. И только. После чего правило для этого бранча прикручивается поверх скажем так метки. Как вариант для напосмотреть хватает просто правила CHECKEDOUT.

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

Кстати описанная вами картина мне очень сильно напомнила как раз SVN :)

Зачем нужны локальные копии? СС строится вокруг понятия вью определяемого спеком. Воркспейсы там не сильно нужны. Любые изменения легко отслеживаются по хистори. ЛЮБЫЕ.

Боишься, что быдло-CC начнёт у тебя вызывать непреодолимое отвращение, стоит только тебе поближе познакомиться с современными DVCS? И потому так убедительно его защищаешь? Как я тебя понимаю, лол.

> Можно критиковать, можно не одобрять то как он работает. Но говорить что он какашка это неправильно.

Проблема только одна. При работе с clearcase я трачу на _порядок_ больше времени чем с другими vcs (и это без учета времени когда нужно вмешательство админа и иногда надо пару дней подождать по починят проблемы с комитом).

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

>Я вас уверяю. Вы прекрасно можете комиттить ваши изменения они лягут на ваш девелоперский бранч. И уже СМ инженер будет разгребать конфликты. Перекладывая дельту на мэйнбранч, вешая метку, выпуская релиз и тд.

Процессов разработки много разных. Каждый день интегрировать со своей ветки в мэйнбранч и обратно — это как-то слишком тяжело выходит.

А реже нельзя, ибо наши товарищи со второй половины планеты хотят наши изменения сразу же, как только проснутся.

>>WFrag

Имхо пример не раскрыт до конца. При любом подходе для того чтоб ваша работа не вылетела в топку надо будет разрешать конфликты с КемТоДругим . Каков бы ни был инструмент, по крайней мере три человека будут решать что выкидывать, а что оставлять (есть же еще некто ГлавныйПрограммер). Для проведения больших изменений в свн можно сотворить отдельные ветки, персонально для Вас и для КемТоДругого. При этом процесс называния друг дружки криворукими чайниками откладывается до объединения вашей и его ветки с основной. Возможно сам процесс разветвления в меркуриал будет выглядеть иначе. Но слияния в любой подобной системе происходят по большому счету одинаково - при помощи молотка , зубила и Кузькиной мамы. Объем ругани зависит как ни странно не от инструмента, а от квалификации ГлавногоПрограммера.

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

> Объем ругани зависит как ни странно не от инструмента, а от квалификации ГлавногоПрограммера.

Если в качестве vcs выбран clearcase - с квалификацией однозначно туго - зато барадака будет выше крыши

> Нет. Это большой минус. Проблема в том, что при таком подходе твоё локальное рабочее состояние нигде не фиксируется, то есть имеем не полную историю.

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

У нас есть скрипт для svn, который автоматизирует синхронизацию приватной бранчи с транком для svn ( http://savana.codehaus.org/ ). В svn 1.5 это должно быть из коробки.

Ну что ж хозяин барин. Значит вам так удобнее :) Спорить не вижу смысла.

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

Это решение совсем другого уровня. Учитывая, что до недавнего времени merge в svn был убогий, это не очень лёгкое решение. Желания каждый день мерджиться два раза у меня нет.

Merge в 1.5 не смотрел, но особых ожиданий нет, говорят, что это аналог svnmerge.py, который не всегда спасает.

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

Если же код разбит на компоненты и суперкомпоненты то все и вовсе чудесато :)

Поймите главное, зачем девелоперу лезть в мэйн бранч? Не его это дело. Его дело багу пофиксать и изменения на своем бранче подать. И фиксать следующее. Да, если реализуется новая фича, уходит немалое время, код убегает вперед. Но. Новая фича это как правило в основном новый код, с довольно незначительным изменением старого. Большого конфликта обычно не возникает, большинство мержей так и вовсе тривиальны.

>Имхо пример не раскрыт до конца.

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

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

>При любом подходе для того чтоб ваша работа не вылетела в топку надо будет разрешать конфликты с КемТоДругим . Каков бы ни был инструмент, по крайней мере три человека будут решать что выкидывать, а что оставлять (есть же еще некто ГлавныйПрограммер). Для проведения больших изменений в свн можно сотворить отдельные ветки, персонально для Вас и для КемТоДругого. При этом процесс называния друг дружки криворукими чайниками откладывается до объединения вашей и его ветки с основной. Возможно сам процесс разветвления в меркуриал будет выглядеть иначе. Но слияния в любой подобной системе происходят по большому счету одинаково - при помощи молотка , зубила и Кузькиной мамы. Объем ругани зависит как ни странно не от инструмента, а от квалификации ГлавногоПрограммера.

Это понятно. Просто в Mercurial описанный мной момент сделан лучше.

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

Я б сказал, как у нас процесс организован, так закидают валенками (за дело, впрочем) :)

>А вот если то что накодили за день (реализовали фичу, пофиксили баг, одним словом проделали какую то законченую работу) и совокупную дельту интегрировали на мэйнбранч, повесили метку выпустили релиз ноты, то почему нет? Все весьма стройно и красиво выходит.

Хз, хз, мне кажется, для нашего случая слишком тяжело. Не говоря уж о том, что не каждый наш девелопер в состоянии провести описанный цикл, этому их ещё учить надо :)

Простите, вы про СС? Я откачу вам что угодно до куда угодно :) Это как мне казалось свойство любой CVS.

Воть. Тут подпишусь всеми руками и ногами.. Когда я вижу чего вытворяют юные девелоперы временами слеза гордости наворачивается на глаза за нашу страну :)

Но согласитесь, грех обвинять в этом инструмент?

А и опять же, какое главное правило разумного человека? Выбирать инструмент по задаче :)

ЗЫ От анонимусов начинает где то кружиться голова :)

>Простите, вы про СС? Я откачу вам что угодно до куда угодно :) Это как мне казалось свойство любой CVS.

Простой эксперимент (SVN):

1) Делаешь какие-то изменения. 2) Кто-то делает изменения в тех же файлах. 3) Делаешь апдейт. Получаешь конфликты, часть смерджилось, часть нет. 4) Как откатиться к моменту до 3, но после 1?

Речь про один бранч. Как уже верно заметили, бранчи позволяют избежать этой ситуации.

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

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

Ваш пример суть профанация самого понятия процесса параллельной разработки :) В моем разумеется понимании. Каждый девеломер живет в своем бранче. Неважно что это за свн. Хотя в случае СС как уже было отмечено отдельный бранч создается на каждый чих, таск, баг и тд. Отправив запрос на интеграцию (указав в нем бранч и версии элементов) девелопер умывает руки. Дальше не его епархия. Иногда его могут подтянуть в случае нетривиального мержа.

Накопившаяся дельта сливается на интеграционный бранч. Он тестится как минимум на санити. После заливается на мастербранч и тэгается меткой.

При подобной схеме как легко понять в любой момент можно откатится на любое желаемое число шагов. Все изменения под контролем.

Причем заметьте, все это прекрасно реализуется в ЛЮБОЙ CVS

Дык в СС и так все построено на ветках сиречь бранчах. На них и подается дельта. Для меня к примеру было поначалу дикостью что в свн можно всю разработку вести в рамках одного бранча обновляя его время от времени с транка. Потом обвыкся но как то все равно тревожит.

>лежать это добро будет на девелоперском бранче и при интеграции на мэйнбранч дельту ломающую билд СМ инженер выкинет нафик.

>В свн мне столь же непринужденно девелоперы заливали битую дельту. Так что технически это тоже возможно :) Кривые руки не победить ничем :)

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

"дельты, ломающие билд" просто не надо заливать в ствол вообще.

В dvcs все по умолчанию и так как раз работают в отдельных девелоперских ветках, при этом сама dvcs умеет *проще* сливать изменения между разными соседними ветками (учитывая что девелоперские ветки, как правило, делаются клонированием из родительской). А если при "подгрузке дельты девелопером в ствол" (hg push) возникнет конфликт, дельта просто не подгрузится. Тогда девелопер при очередном чекауте разруливает конфликт сам, и сам заново подгружает. Или делает патч (hg bundle/hg outgoing/hg export) и посылает автору, который его получает/просматривает (hg incoming, применяет hg unbundle, или откатывает hg revert / hg backout /hg bisect (для поиска, что именно откатывать), если "дельта не грузиццо")

СМ инженер в простейшем случае не нужен: автор может политически принимать только те патчи, которые "грузяццо" (и откладывать патчи ломающих девелоперов), а девелопер фичи -- соответственно протестировать, чтобы грузилось. То есть, роль "CM инженера" ложится в основном на девелопера отдельной фичи (который выдает такие дельты, чтобы "грузилось") и на автора-ментейнера, который принимает только неломающие дельты. За счёт атомарности коммитов, получаем что при каждом коммите в стволе билд обязан собраться. А бранчи сливаются автоматически, за счёт того, что все и так по умолчанию в разных ветках. Если дельты разных девелоперов не накладываются, то их и слить в ствол можно автоматически. Вот если "девелопер отдельной фичи" не может собрать билд целиком, тогда да, приплыли.

> Ему совершенно не нужны ВСЕ исходники. Ему нужен бранч с измененными им элементами.

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

Я сильно не уверен что можно на 100 процентов гарантировать что дельта залитая "в ствол" не поломает билд. Хорошо, пусть дельта залитая всегда будет компилябельна (не взирая на усилия девелопера, хотя тяжело мне в это поверить). Но все равно тестирование остается на его совести. Как говорится ЮниитТест необходим но не достаточен.

Это чревато. Тестировать должен совсем иной человек. И по хорошему только на основании тестирования решать брать дельту или нет. Не забываем что в цикле разработки важную часть занимает не только CVS но и DTS.

Второе. При прямой заливке "в ствол" откатить будет сложнее. И главное когда у вас 10-20-30 продуктов имеют сложное переплетение наследования и вливания друг от друга, что считать стволом? При подаче патча ситуация отличается от описанного мной только механизмом.

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

То что в простейшем случае "СМ инженер" не нужен прекрасно понятно. Беда в том что СС разрабатывался совсем уж не для простых случаев, в этом его сила и горе одновременно.

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

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

вот есть Вася и Петя, которые добавляют в программу две новых фичи. 1. Вася добавляет один класс, Петя добавляет другой новый класс. Конфликтов нет.
2. Вася рефакторит один аспект, Петя добавляет другой новый класс. Конфликтов нет.
3. Вася рефакторит один аспект старого кода, Петя -- другой. Конфликт может быть, а может и не быть. Если их изменения накладываются.
Тогда они не смогут слиться между собой, но каждый из них по отдельности может слиться в ствол.

> Объем ругани зависит как ни странно не от инструмента, а от квалификации ГлавногоПрограммера.

Ну да, если ГП разбил основную работу по варианту 3, это естественно.

А если Петя при попытке слить в ствол получил конфликт -- тогда он ССЗБ, и ему надо отрефакторить своё изменение, чтобы смог слиться. Он берёт ветку Васи, его патч в этой ветке и свой патч, и смотрит, где они начали расходиться. Смотрит автоматом, через hg bisect: если с патчем от начала ветки Васи до N ревизий его патч сливается успешно, а с патчем из Васиной ветки длиной (N+1) возникает конфликт, значит, в (N+1)-й ветке Васи и в голове ветки Пети ветки разошлись. Значит, надо с этого места Пете переписать свой патч (но предыдущие N патчей из Васиной ветки наложатся автоматически).

при этом и в девелоперских ветках, и в стволе останутся рабочие версии. То есть, Петя переписывает патч в ветке своей девелоперской ветки.

Ну или ГП может этим заниматься, если он ССЗБ и кроме него никто билд собрать не может (или Петя не знает о Васе). или если ему нужно "рефакторить много патчей", и так, чтобы все накладывались.

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

cat ~/.subversion/config

[miscellany]
global-ignores = *.o *.lo *.la *.a *.so #*# .*.rej *.rej .*~ *~ .#* .DS_Store

svn rm ...

Зачем? Зачем ему исходники 2 веток? С этим прекрасно справится команда merge.

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

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

Не нужно ничего выкачивать. Все происходит прямо на вью сервере.

> svn rm ...

svn rm не убирает файл, который уже попал в репозиторий - для этого необходим dump/load.

> Как только ты делаешь апдейт и получаешь конфликты — назад пути нет. Часть файлов смерджилась, часть нет и откатиться до момента апдейта уже не получится.

фсмысле? hg revert, или hg bisect чтобы найти LKG ревизию.

В условиях большого количесва сильно разнесенных девелоперов Вася о Пете как раз обычно и не знает. Точнее речь о внесенных изменениях. Ну и общее число Вась и Петь сильно больше 2.

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

> Но согласитесь, грех обвинять в этом инструмент?

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

А так да, на бензопиле вон тоже disclaimer пишут, инструмент-то не виноват :)

>ЗЫ От анонимусов начинает где то кружиться голова :)

да их тут сотни !!! :)

> Тестировать должен совсем иной человек. И по хорошему только на основании тестирования решать брать дельту или нет.

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

> При прямой заливке "в ствол" откатить будет сложнее.

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

> И главное когда у вас 10-20-30 продуктов имеют сложное переплетение наследования и вливания друг от друга, что считать стволом?

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

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

На самом деле, интересно конечно накатывать/откатывать патчи целиком между ветками (или разными продуктами). Посмотрите возможности git rebase, hg patch queues

http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension#head-d1766b2cce00... http://benjamin.smedbergs.us/blog/2007-11-30/merging-with-mercurial-queues/ http://www.canonware.com/~ttt/2008/04/using-mercurial-patch-queues-for-daily.... http://kerneltrap.org/mailarchive/git/2007/10/31/373985 http://jbowes.dangerouslyinc.com/2007/01/26/git-rebase-keeping-your-branches-... http://blog.moertel.com/articles/2007/12/10/how-i-stopped-missing-darcs-and-s... http://kerneltrap.org/node/11753

> Разговор становится слегка ни о чем. Разве что об удобстве тривиальных операций. Но это во многом дело привычки и дисциплины.

Плюс о возможных workflow для облегчения тех же действий.

сравнения: http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Dis... http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html

>предварительное тестирование по идее должен делать робот - buildbot или типа него. Функциональное тестирование и приёмку -- да, делать человек, но на основании пройденных предыдущих этапов тестирования.
Предварительное тестирование это ЮнитТест. За него отвечает как раз девелопер.
Функциональное человек, но на основе подготовленного набора тестов покрывающих описанную функциональность.
Тесты как правило пишутся по дизайну (но ту на практике возможны разнообразные варианты :))

>не сильно -- всегда есть девелоперский бранч, из которого заливается, и протестированная версия в стволе, но при желании тут можно навертеть сложностей вроде теории совместимых патчей в darcs
Да, вероятно не сильно, но мне кажется что ситуация когда из главной ветки удаляется дельта должна быть исключительной а не обыденной. Зачем засорять мэйнлайн всяким мусором? Его и так хватает на девелоперских бранчах. И никуда он оттуда не денется.

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

>На самом деле, интересно конечно накатывать/откатывать патчи целиком между ветками (или разными продуктами). Посмотрите возможности git rebase, hg patch queues
Почитал про git. Очень любопытно. Буду думать что тут не так :)

>Плюс о возможных workflow для облегчения тех же действий.
А это не так сложно реализоать скриптами.

PS Кролик открыл для себя кнопку Ф8. В том смысле что я открыл для себя как переносы делать :)