Кто/что мешает коммитить не в trunk, а в branches? Главная ветка не тронута, тестируй сколько угодно. Оттестировал - мержи.

Накладные проблемы и т.д. Никто не станет создавать отдельную ветку ради 1 патча. 
Я ещё не полностью въехал в DVCS. Но Линус говорил об этом.

да-а? то есть то, что ты создавал 7 минут свой отпечаток репозитория - нормально. А ветку жалко, да?
Да и потом. Если надо всего лишь 1 патч - нафиг тогда ветка - слил, действительно, последнюю ревизию себе, у себя проверил, доложился.

Посмотрел выступление Линуса. Вот такие преимущества DVCS он называл:

 - offline working:
т.е. когда нет доступа в сеть (к главному репозиторию) можно продолжать работать: смотреть историю, коммитить,...

 - branching and merging:
всякий локальный репозиторий фактически является веткой (по отношению к любому другому), возможно слияние с другим репозиторием с сохранением полной истории изменений из обоих, что позволяет постоянно держать локальную ветку в актуальном состоянии; в отличии от веток в централизованных системах локальные изменения никто не видит до той поры, когда нужно протащить изменения в другой репозиторий; 

 - commit access:
нет проблемы с выбором тех, кому позволено коммитить в репозиторий, т.к. фактически у каждого свой личный репозиторий (особенно для open source проектов актуально);

 - strict commiting rule:
почти всегда, чтобы закоммитить код, нужно его сначала хорошо оттестировать; получается, что невозможно коммитить малые изменения, логически связанные куски, а вместо этого происходит допиливание кода до приемлемого состояния и затем делается один большой коммит, в котором потом будет сложно разобраться;

- network of trust:
основной разработчик (project leader, maintainer,...) работает непосредственно с несколькими другими, которым он доверяет; изменения он берет только у них, а они в свою очередь таким же образом работают; когда возникают кофликты при слиянии изменений, то их не обязательно разрешать основному разработчику, синхронизацию могут делать непосредственно те, кто вносил изменения, приведшие к конфликту (nobody is special);

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

- consistency check (security):
все ревизии подписаны SHA1 и проверяются при работе с файлами; если известна подпись ревизии, то вся история изменения вплоть до этой ревизии может быть получена из любого источника и можно быть уверенным, что никто ничего не подменил.

kamre, спасибо, добротный обзор 

http://video.google.com/videoplay?docid=-7724296011317502612
О меркулар. Оффтоп, но интересное видео. Посмотреть в спокойной обстановке не смог, пересмотрю на выходных.

для mercurial есть клиент под винду - tortoisehg

 Для тех кто не осилил этот доклад (лень/долго смотреть/не идет английский на слух) предлагаю 
перевод-стенограмму  (по переводу — претензии мне) доклада вместе с слайдами и другими кадрами видео. 
Посмотрите/проникнитесь/посмейтесь…