Mercurial практики: использование с IDE и масштабируемость

Question

Я не опытный пользователь инструментов SCM, хотя, конечно, убежден в их полезности. Я использовал какой-то непонятный коммерческий инструмент на прежней работе, Perforce на текущей, и немного поиграл с TortoiseSVN для своих маленьких личных проектов, но мне не нравилось иметь много папок .svn повсюду, делая поиск, резервное копирование и многое другое. сложно. Затем я обнаружил интерес к распределенной SCM и решил пойти по-видимому более простым (чем git) Mercurial, но все же для моих личных, индивидуальных потребностей. Я нахожусь в процессе обучения правильному использованию, прочитав часть вики и находясь в середине превосходной книги в формате PDF.

Я вижу часто повторяющиеся, например, в Методы работы Mercurial , ", не стесняйтесь использовать несколько деревьев локально. Mercurial делает это быстро и легко. " и " для каждой функции, над которой вы работаете, создайте новое дерево.". Это интересные и разумные советы, но они немного мешают моим маленьким привычкам с централизованным SCM, где у нас есть «священный» центральный репозиторий, где ветки тщательно планируются (и обрабатываются администраторами), списки изменений должны проверяться (старшими) коллегами и не должны ломать сборки и т. д. :-) Начало работы над новой веткой занимает довольно много времени ...

Итак, у меня есть два вопроса в свете вышесказанного:

• Насколько практично делать много клонов в контексте IDE и тому подобного? Что если в проекте есть файлы конфигурации / настроек, make-файлы или сценарии Ant, сценарии оболочки или что-то еще, требующие обновления пути? (да, вероятно, плохая идея ...) Например, в Eclipse, если я хочу скомпилировать и запустить клон, мне нужно сделать еще один проект, настроить путь сборки Java, цели Run / Debug и т. д. , Если плагин Eclipse не облегчит эту задачу. Я скучаю по чему-то здесь?

• Как это масштабируется? Я прочитал Hg в порядке для больших баз кода, но я озадачен. На моей работе у нас есть Java-приложение (ну, несколько вокруг большого общего ядра) примерно в 2 миллиона строк, весом около 110 МБ только для кода. Создание чистой компиляции на моей старой (2004 г.) рабочей станции Windows занимает около 15 минут, чтобы сгенерировать 50 МБ файлов классов! Я не вижу себя клонирующим весь проект, чтобы изменить 3 файла. Так какие здесь практики?

Я еще не видел, чтобы эти вопросы рассматривались в моих чтениях, поэтому я надеюсь, что это создаст полезную тему.

Answer 1

Вы подняли несколько хороших очков!

• Насколько практично делать много клонов в контексте IDE и тому подобного?

Вы правы, что может быть трудно управлять многими клонами, когда IDE и другие инструменты зависят от абсолютных путей. Частично это можно решить, всегда используя относительные пути в ваших файлах конфигурации - уверенность в том, что проверка исходного кода может быть скомпилирована из любого места, сама по себе является хорошей целью, независимо от того, какую систему контроля версий вы используете:

Но если вы не можете или не хотите беспокоиться о нескольких клонах, обратите внимание, что один клон может справиться с несколькими ветвями . «Hgbook» подчеркивает многие клоны, так как это концептуально простой и очень безопасный способ работы. Когда вы приобретете больше опыта, вы увидите, что вы можете использовать несколько головок в одном репозитории (возможно, назвав их закладками ), чтобы сделать то же самое.

• Как это масштаб?

Клонирование репозитория 110 МБ должно быть достаточно быстрым: это зависит от того, сколько времени потребуется для записи 110 МБ на ваш диск. В недавнем сообщении в список рассылки Mercurial сообщалось, что клонирование 6,3 ГБ заняло 4 минуты - уменьшение до 110 МБ дает около 4 секунд. Это должно быть достаточно быстрым, чтобы ваш чай был еще теплым :-) Часть хитрости в том, что данные истории просто жестко связаны (да, и в Windows), и поэтому нужно только записать файлы в рабочем состоянии. копия.

Answer 2

PhiLo: я новичок в этом, но у mercurial также есть «внутренние ветви», которые вы можете использовать в одном репозитории вместо клонирования.

Вместо

hg clone toto toto-bug-434

вы можете сделать

cd toto
hg branch bug-434
hg update bug-434
...
hg commit
hg update default

чтобы создать ветку и переключаться туда-сюда. Ваши встроенные файлы, не находящиеся под контролем оборотов, не исчезнут, когда вы переключите ветки, некоторые из них просто устареют, поскольку базовые источники будут изменены. Ваша IDE восстановит то, что нужно, и не более. Он работает так же, как CVS или Subversion.

У вас должны быть чистые «входящие» и «исходящие» репозитории в дополнение к вашему «рабочему» репозиторию. Просто ваша «работа» может служить нескольким целям.

Тем не менее, вы должны клонировать свое рабочее репо, прежде чем пытаться что-либо запутать. Если что-то пойдет не так, вы можете выбросить клона и начать все сначала.

Answer 3

Вопрос 1:

PIDA IDE имеет довольно хорошую интеграцию с Mercurial. Мы также используем Mercurial для самой разработки. Лично у меня есть около 15 параллельных клонов, идущих из некоторых проектов, и IDE отлично справляется. У нас нет проблем с настройкой скриптов сборки и т. Д., Мы можем «клонировать и пойти».

Это так просто, что во многих случаях я буду клонировать номер ошибки, например:

hg clone http://pida.co.uk/hg pida-345

Для ошибки # 345, и я готов исправить.

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