mercurial - второй взгляд

Продолжаю разбираться с mercurial. Впечатления:

1. Оказывается, на официальном сайте лежит официальный русскоязычный  туториал.
2. При установке mercurial ubuntu удалила bazaar. С горя? :-)
3. Локальный репозиторий mercurial это и есть working copy. Только check in (commit), как и в других системах, надо делать руками.
   Соответственно, если почаще делать check in, то подробная история будет легко автоматом сливать изменения.
4. Mercurial очень шустро работает. Там, где svn на простых проектах работал пару секунд, mercurial дает мгновенный отклик.
5. Плагин для Eclipse у меня в конце концов заработал. Но из командной строки все делается проще и понятнее.

Что дальше - буду пробовать использовать на реальных проектах. Если будет наклевываться коллективная разработка - выложу на bitbucket или аналог.

Начал читать про mercurial

Начал читать про mercurial. Основные заинтересовавшие меня моменты.

1. Centralized VCS (CVCS): Два пользователя заливают одни и те же файлы в репозиторий. Первый просто заливает, второй делает merge. Его личные изменения нигде не сохраняются.
   Distributed VCS (DVCS): все индивидуальные изменения сохраняются в виде отдельных ревизий.
2. Можно дать полноценные ревизии коллеге (в специальном архиве - bundle), не выкладывая их в центральный репозиторий (самое интересное, что bundle для системы выглядит как обычный read-only репозиторий, его не надо как-то хитро распаковывать). В свою очередь, коллега может, например, сделав Code review, уже сам закинуть эти ревизии в центральный репозиторий.
3. Нельзя быстро порушить систему, тупо убив центральный репозиторий.
4. Можно парой команд получить список ревизий, которые не приняты сверху в свой клон репозитория и наоборот - которые не отправлены наверх.
5. Можно посмотреть граф ревизий (кто для кого является родительской).
6. В отличие от TFS есть полноценный откат ревизии с нормальным сохранением истории (что делается именно откат).
7. Есть grep, который ищет по всем файлам и всем ревизиям (можно наложить фильтры, чтобы искать не по всем).
8. Теги хранятся не в мифических метаданных, а обычным файликом (с поддержкой версионности). Причем могут быть локальные (только для своего репозитория) и глобальные.
9. Нет встроенной утилиты для слияния (кто не любит ручками ставить meld, ediff, winmerge и т.п., будут плакать).
10. Нельзя задать имена для веток в графе ревизий репозитория (named branch). Хотя здесь не до конца разобрался, надо читать дальше и пробовать.
11. Для команд можно задавать алиасы (чтобы не писать большую портянку).
12. Есть готовая команда для поиска багов (и прочей лажи) по ревизиям  методом половинного деления.
13. Можно автоматом слать патчи и/или бандлы по почте.
14. Есть встроенные инструменты для фиксации отдельных изменений (отдельными ревизиями) в большом файле.
15. Есть интерфейсы к веб-серверу и Trac'у.
16. Для категорических противников командной строки есть GUI-клиент (TortoiseHg) и интеграция с IDE (Eclipse, IntelliJ IDEA, Visual Studio).
17. Есть нормальная поддержка патчей на уровне системы (они не будут прятаться в обычных ревизиях, а могут развиваться вместе с репозиторием).

Долго не мог понять, почему же merge в mercurial проходит намного легче, чем в CVCS. Оказалось: из-за более подробной истории изменений (история из локального репозитория разлетается дальше). Не совсем пока разобрался в связке working copy с локальным репозиторием - но это, видимо на практике пробовать надо.

В итоге достаточно легко делать штуки, от которых разработчики, использующие SVN или TFS просто шарахаются:

• заводить отдельную ветку (репозиторий) на фичу;
• дать разработчикам выкладывать код в репозиторий "testing", а из него в "stable" - только тестерам.