https://www.opennet.ru/openforum/vsluhforumID3/81151.html Увидел свет (http://www.selenic.com/pipermail/mercurial/2011-November/040631.html) релиз распределенной системы управления версиями Mercurial 2.0 (http://mercurial.selenic.com). Версия 2.0 не отличается кардинальными изменениями, смена первой цифры является следствием принятых в проекте правил нумерации релизов (после версии 1.9 выходит не 1.10, а 2.0).<br><br><br>Ключевые изменения (http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.0_.282011-11-01.29):<br><br><br><br>- Новая команда graft (http://www.selenic.com/mercurial/hg.1.html#graft), реализующая функциональность сходную с расширением transplant. Команда graft позволяет скопировать отдельные изменения из другой ветки без непосредственного слияния веток, что существенно упрощает выполнение таких операций как бэкпортирвоание изменений;<br><br><br>- В состав включено расширение largefiles (http://mercurial.selenic.com/wiki/LargefilesExtension) для работы с помещаемыми в репозиторий большими бинарными файлами, которые плохо сжимаются, не пересекаю...<br><br>URL: http://www.sel https://www.opennet.ru/openforum/vsluhforumID3/81151.html#59 Wed, 09 Nov 2011 11:53:47 GMT &gt; А, то-есть возражений по поводу того что при _практическом_ использовании с дефолтными настройками хг в отличие от гита тормоз вы не имеете?<br><br>prove it. у меня hg не тормозит. bzr медленный, да. а hg летает. ЧЯДНТ?<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#58 Wed, 09 Nov 2011 11:37:11 GMT &gt; Блин ... цитируя Филатова - "Зарядила как удод- что не слово то <br>&gt; Федот!" - это про соседние диры <br><br>А, то-есть возражений по поводу того что при _практическом_ использовании с дефолтными настройками хг в отличие от гита тормоз вы не имеете? <br><br>&gt; Резюме - Чукча хэлп не читал и в руках не держал .... <br><br>Посмотрев на то как оно в разы сливает гиту на типовых операциях с репами исходников, а не какими-то больными на голову бэкэндами для вебни - я разумеется напер на изучение гита, а не этой странной хрени.<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#57 Mon, 07 Nov 2011 23:18:43 GMT &gt;&gt; _Иногда_ стабильность важнее скорости вливания фич. :) <br>&gt; В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро, <br>&gt; и не разваливая основное дерево.<br><br>Нет, я имел в виду конечную разрабатываемую систему. Где новые фичи разрабатываются не очень часто, а вот сам процесс ревью довольно жёсткий. Одно дело - видеоплеер у хомячка грохнется, и другое - сбой на конвеере завода или на web-сервисе с посещаемостью на уровне "Яндекса" или "Википедии". Повторюсь, специфика везде своя. :)<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#56 Mon, 07 Nov 2011 20:37:06 GMT &gt; _Иногда_ стабильность важнее скорости вливания фич. :) <br><br>В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро, и не разваливая основное дерево.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#55 Mon, 07 Nov 2011 17:18:37 GMT Может простОте? Или вы реально имел в виду прост`ату?<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#54 Mon, 07 Nov 2011 15:01:49 GMT &gt; фиче-бранчи на двух-трёх человек становятся чудом.<br><br>... в том смысле, что фиче-бранч предполагает, во-первых, что изменения колбасятся быстро, без ожидания аппрува каждого коммита прежде чем приступить к следующему, а, во-вторых, работу над одним и тем же кодом ведут несколько человек. Соответственно, у них гарантированно будут пересечения по коду и они будут вынуждены корректировать свои коммиты при изменении коммитов где-то в глубине цепочки/дерева.<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#53 Mon, 07 Nov 2011 14:57:25 GMT &gt;&gt; При жёстком требовании использования небольших атомарных коммитов это не проблема.<br>&gt; фиче-бранчи на двух-трёх человек становятся чудом.<br><br>_Иногда_ стабильность важнее скорости вливания фич. :)<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#52 Mon, 07 Nov 2011 14:55:39 GMT &gt; При жёстком требовании использования небольших атомарных коммитов это не проблема.<br><br>фиче-бранчи на двух-трёх человек становятся чудом.<br> https://www.opennet.ru/openforum/vsluhforumID3/81151.html#51 Mon, 07 Nov 2011 06:46:03 GMT &gt; Точнее так: <br>&gt; когда я последний раз смотрел на Review Board, он весь строился вокруг <br>&gt; концепции патча.<br>&gt; Соответственно, работа с цепочкой изменений, отправленных на ревью, становилась, м-м-м, <br>&gt; мягко говоря, неочевидной. Ну, разумеется, предполагается, что в ходе ревью какие-то <br>&gt; из присланных ченджсетов в цепочке будут изменены, какие-то вообще могут быть <br>&gt; выброшены, ну и так далее.<br><br>Это зависит от организации процесса... При жёстком требовании использования небольших атомарных коммитов это не проблема. Такое требование имеет свои плюсы в случае обнаружения регрессий уже после коммита - shit happens. Но в более мягкой ситуации, при разработке типичного десктопного приложения - да, будет неудобно.<br>