Библиотека сайта rus-linux.net
Архитектура Mercurial
Глава 12 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: "Mercurial".
Автор: Dirkjan Ochtman
Перевод: Vlad http://vlad8.com/
12.6. Выводы
Одним из первых решений, которое принял Мэтт, когда начинал разработку Mercurial, было то, что разрабатывать надо на Python. Python зарекомендовал себя с самой лучше стороны с точки зрения расширяемости (через расширения и перехватчики), и на нем очень легко писать код. Он также берет на себя большую часть работы по совместимости кода между различными платформами, что достаточно легко дает возможнсть Mercurial успешно работать с тремя главными операционными системами. С другой стороны Python медленный, по сравнению со многими другими (компилирующимися) языками; в частности запуск интерпретатора достаточно медленный, что не очень хорошо для инструментов, которые запускаются много и часто (таких как система контроля версий), а не работают как долговременные процессы.
Также одним из ранних решений была сложность модификации изменений после их коммита. Так как невозможно изменить версию без модификации ее идентифицирующего хэша, «обратный вызов» изменений после их публикации в Интернете приносит проблемы, и поэтому Mercurial не дает выполнить такую операцию. Однако, изменение незафиксированных версий не должно быть затруднено, и сообщество пыталось упростить этот процесс вскоре после релиза. Существуют расширения, которые пытаются решить эту проблему, но они требуют определенного обучения и не являются интуитивно понятными для пользователей, которые до этого пользователись только основными функциями Mercurial.
Revlog хороши тем, что позволяют уменьшить количество обращений к диску; послойная архитектура лога изменений, манифеста и файлового лога также показала себя с хорошей стороны. Коммит изменений осуществляется быстро и достаточно мало дискового пространства используется для хранения версий. Однако, некоторые операции, например, переименование файлов, выполняются не очень эффективно из-за раздельного хранения версий для каждого файла; в конце концов это будет исправлено, но потребует какого-то нестандартного хака, нарушающего текущую концепцию слоев. Аналогично, пофайловый направленный ациклический граф, используемый для помощи в хранилища файлового лога, не используется на практике достаточно широко, поэтому код, используемый для работы с этими даными может быть посчитан излишним.
Еще одним ключевым фактором для Mercurial была необходимость легкости в обучении. Мы старались собрать большинство требуемых функций в небольшой набор команд со схожими опциями. Идея состояла в том, чтобы Mercurial можно было изучить прогрессивно, особенно тем пользователям, которые использовали другие системы контроля версий до этого; эта философия расширяется до такой степени, что расширения могут быть использованы для модификации Mercurial еще больше в каждом конкретном случае. По этой причине разработчики также пытались создать пользовательский интерфейс, схожий с другими системами контроля версий, Subversion в частности. Также команда попыталась предоставить хорошую документацию, доступную из самого приложения, со ссылками на другие части справки и информацию о командах. Мы следим за тем, чтобы сообщения об ошибках имели смысл, включая подсказки что еще можно сделать вместо той операции, которая завершилась ошибкой.
Некоторые менее важные решения могут быть удивительными для новых пользователей. Например, управление тэгами (как обсуждалось в предыдущей секции) путем хранения их в отдельном файле внутри рабочей директории не понравилось по началу многим пользователям, но данный механизм имеет некоторые весьма ощутимые преимущества (хотя и не лишен недостатков). Кроме того, другие системы контроля версий по умолчанию посылают на сервер изначально загруженные изменения и их предков, в то время как Mercurial посылает каждое зафиксированное изменение, которого нет на удаленном сервере. Оба подхода имеют определенный смысл, и каждый подходит для определенного стиля разработки.
Как и в любом программном проекте, нам пришлось идти на множество компромиссов. Я считаю, что в случае Mercurial мы во многом делали правильный выбор, хотя если оглянуться назад, безусловно, что-то можно было сделать иначе. Исторически, Mercurial оказался частью первого поколения распределенных систем контроля версий, достаточно зрелых для широкого использования. Что касается меня, то я хотел бы увидеть, как будет выглядеть следующее поколение таких систем.
Вернуться к началу статьи.