HomeМеркуриал в последнее время стал моей основной системой контроля версий, и естественно у меня появился некоторый опыт, которым по моему мнению пора бы и поделиться.
Начнем с небольшого сравнения со старым добрым Subversion.
Долго пытаясь вспомнить недостатки децентрализованных система контроля версий нашел только один: возможность фальсификации авторства коммита — для проектов в которых я участвую такая фальсификация не несет никому никакого вреда, а потому я не считаю это большим недостатком.
Чуть позже при написании статьи вспомнил еще один, уже достаточно серьёзный недостаток — невозможность забрать часть репозитория. В любой современной децентрализованной системе контроля версий репозиторий является единой сущностью, а потому стянуть на машину разработчика только часть репозитория, как в Subversion и CVS не выйдет. Однако проблема с разделением репозитория решается именно его РАЗДЕЛЕНИЕМ.
Теперь попытаюсь вспомнить преимущества.
Локальный игнор-файл — файл содержащий паттерны для исключения файлов/каталогов из-под контроля версий может контроллироваться системой, а может быть так же исключен из-под контроля. Последний вариант дает разработчикам огромные возможности для хранения внутри рабочей копии дополнительных файлов, таких, как например инструменты разработчика, sql-дампы, да все, что только можно придумать. Простейший пример: Одни разработчики используют Eclipse, другие Netbeans, третьи Komodo, а каждая из этих сред создает в корне проекта файлы с мета-информацией о проекте. Включать эти файлы и папки в контроль версий смысла нет, а добавлять все возможные варианты в игнор, грозит его разрастанием.
Автоматический бэкап. Это преимущество неоспоримо, ведь каждый из разработчиков имеет на своей машине самодостаточный репозиторий, который можно в любой момент сделать главным (ну если вдруг сервер упал… с пятого этажа).
Получается, что главным преимуществом распределенных систем контроля версий является именно их распределенность. Преимущества этой распределенности распознаются разработчиками далеко не сразу, а только тогда, когда приходит некоторый опыт использования DVCS, потому я сейчас попробую обяснить удобства этой самой распределенности на примерах.
Для начала немного теории! Помните централизованные системы контроля версий? Там есть единый репозиторий в который мы коммитим и с которого обновляем нашу рабочую копию. В распределенных системах репозиторий находится прямо внутри рабочей копии. В Меркуриал репозиторий хранится в каталоге .hg прямо в корне проекта (рабочей копии). Все фиксации изменений и обновления происходят локально. Казалось бы все как и в централизованной системе, однако при надо же как-то делиться изменениями с другими разработчиками? Вот тут и начинается та самая распределенность. Чтобы опубликовать (протолкнуть в терминологии Mercurial) наши изменения в общий репозиторий (вспоминаем? система распределенная – репозиториев много) мы должны их сначала зафиксировать локально (commit), и только потом отправить в обший репозиторий (push). Для того, чтобы получить чужие изменения в свой локальный репозиторий (втягивать в терминологии Mercurial) мы должны выполнить комманду pull (тянуть). Когда чужие изменения уже находятся в нашем репозитории мы можем иметь 2 ветки изменений – 1) ветка наших изменений с несколькими коммитами 2) ветка чужих изменений тоже с несколькими коммитами. Ветки в итоге сходятся к одному родительскому узлу (changeset или «набор изменений» в терминолонии Меркуриал)
…… продолжение следует…
Похожие посты:
- Mercurial Queue Пришел в восторг, попробовав очередь патчей в HG. Настраиваем рабочую...
- Mercurial 1.5 released Что нового? Core Улучшено поведение именованных веток с коммандой heads...
- PHP и NetBeans Недавно открыл для себя NetBeans IDE. У меня почему-то начал...
- Непонятный глюк Subversion Вот и случилось непонятное с ситемой контроля версий... А я-то...
- Internet Explorer для Linux У веб-мастеров, работающих в Linux возникает достаточно острая проблема - ...