Учитывая переход на Mercurial или Git? Мы тоже. В настоящее время я изучаю преимущества DVCS, которые оказываются огромными, жаждут и должны.
Мне бы хотелось услышать от типичных шаблонов использования сообщества.
Позвольте создать список функций производительности "Top N" для DVCS (на основе Mercurial, Git или аналогичного).
Просьба описать рабочие потоки, которые окажутся продуктивными для вас/вашей команды, процедуры, которые DVCS помогли вам достичь/улучшить, а также тупые "хорошие вещи", которые дает вам DVCS (не предполагайте, что материал понятен начинающему пользователю).
Я думаю, что такой список может помочь людям приблизиться к команде с предложением DVCS.
Этот вопрос, очевидно, является wiki сообщества.
Единственная истинная функция убийцы - это...
объединение
DVCS (Git, Mercurial или другие) предназначены для слияния (именно потому, что, будучи распределенным, объединение является ключевой функцией, позволяющей этим инструментам быстро интегрировать код, поступающий из разных удаленных репозиториев).
SVN не соответствует задаче (даже сегодня).
См:
Разделение на публикацию
Это важно для более крупных функций, потому что это означает, что можно выполнить ряд коммитов для реализации функции (каждая фиксация является малой и самодостаточной, для легкого поиска ошибок путем дезактивации истории) до одного собственного удовлетворения и только когда они готовы опубликовать их.
Вариант этого подхода состоит в том, чтобы иметь отдельный публичный репозиторий с перестраиваемой веткой с незавершенной работой и нажимать (или отправлять запрос на перенос) только тогда, когда ветка готова для проверки.
Кажется, что для нас "приложение-убийца" превратится в возможность проталкивать код через этапы.
У нас будет репозиторий DEV, который все разработчики нажимают на него. QA repo будет принимать push от репо DEV и будет строить его версию кода для тестирования. Как только тестирование будет завершено, они будут подталкивать код к производственному репо (репозиторий QA является единственным, который может подтолкнуть изменения к производственному репо), из которого будет создаваться выпуск продукции.
Это кратко изложено в Joel hginit (в нижней части страницы).
Я обновлю это сообщение, как только мы осуществим описанную выше настройку.
Для проектов OSS:
низкий барьер входа для вклада
Во-первых, у большинства DVCS есть отличные инструменты для работы с исправлениями (обычно отправляемыми по электронной почте), как для их создания, так и для их применения. Участник может создавать патч с использованием любых инструментов (хотя было бы лучше создать патч с помощью DVCS, используемого проектом, поскольку некоторые DVCS добавили дополнительную информацию в патчи), и отправили его в список рассылки проекта или непосредственно в поддержку проекта, или прикрепить его к отчету об ошибке/запросу функции в трекере проблем.
Во-вторых, вам не нужен бит фиксации, чтобы внести свой вклад. Просто клонировать проектный репозиторий, и вы можете использовать полную мощность DVCS. Затем вы можете отправлять патчи или запрос на растяжение или нажимать на ветку "моб"; есть много возможностей.
Это преимущество также для сторонников проекта: ему не нужно беспокоиться, кому он может доверять, чтобы дать "бит фиксации", то есть доступ к репозиторию, как это имеет место в CVCS. Карл Фогель написал в Создание программного обеспечения с открытым исходным кодом. Как запустить успешный проект бесплатного программного обеспечения., что он нашел лучше для проекта, что ограничения, такие как контроль доступа, будут скорее социальными, чем технологическими; DVCS делает это еще больше, не требуя принятия решения о предоставлении разрешения на совершение.
Большая функциональность доступна в автономном режиме
С централизованным VCS, таким как Subversion, единственное, что вы можете сделать, когда офлайн - это редактировать. Некоторые системы предоставляют ограниченный доступ к другим функциям (например, в Subversion, которые вы можете отличить и вернуться к последней версии из репо), но большая часть того, что делает VCS полезным, то есть
возможно только при подключении к центральному серверу.
При использовании DVCS все описанные выше операции работают локально, и если что-то нужно зайти на центральный сервер, вы всегда можете нажать его там позже, когда вы снова в сети.
Хотя это, вероятно, неважно, если вы всегда в сети (например, в офисе), это может иметь решающее значение, если вам часто приходится работать в автономном режиме, например, во время поездок или дома с откидным соединением.
Я начал использовать git специально потому, что часто работаю на дороге и обычно не имею (надежного) подключения.
"Приложение-убийца" кажется распределенными командами: вместо привязки к центральному серверу (через медленное или ненадежное соединение) каждая команда может иметь свой собственный репозиторий и вносить изменения по мере необходимости.
Обмен изменениями с другими пользователями без публикации
Для меня приложение-убийца, когда я было большой командой, было в состоянии работать вместе с другими инженерами, обмениваться изменениями, без необходимости проходить через центральный сервер. Это означало, что мы могли бы управлять незавершенными функциями контролируемым образом (т.е. "Копировать этот файл с моего дерева" ), и все это просто сработало.