Насколько подходящий DVCS для корпоративной среды?

Все зависит от того, как вы хотите работать над проектами. Распределенные среды отлично подходят, если каждый хочет построить свою собственную ветку. Я предпочитаю центральный репозиторий для своей работы (в небольшой команде), так как это заставляет разработчиков задуматься о выпуске одной версии нашего продукта.

По моему опыту, я вижу много пользователей DVCS, которые думают о своих собственных изменениях как об изменениях. им не нужно просматривать, и эти пользователи просматривают изменения всех других разработчиков, прежде чем объединить их в свое собственное дерево. Мне нравится рассматривать свои изменения как изменения в основном продукте, поэтому я просматриваю эти изменения перед их фиксацией. В результате мы стараемся поддерживать стабильность продукта на протяжении всего цикла разработки. Рефакторинг работает нормально, поскольку все мы часто обновляемся.

Несколько знакомых мне пользователей DVCS предпочитают работать над своей функцией в независимом дереве и оставлять интеграцию с центральным продуктом на заключительном этапе своей разработки. Это отлично работает, если функция является независимой, но я бы не хотел быть тем, кто должен интегрировать все функции, разработанные таким образом, с близким сроком.

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

Лично я считаю это огромным преимуществом. Даже с центральным репо, DVCS изменяет поток с «редактировать код, обновлять из центра, фиксировать» на «редактировать код, фиксировать, отправлять в центральный». Помимо прочего, это означает, что разрешение конфликта гораздо менее напряженное. Это также может стимулировать разработку небольшими частями, поскольку вам не нужно нажимать после каждой фиксации. Если ваша команда согласна с этим, это означает, что ваши отдельные коммиты могут оставить приложение в странном состоянии, если оно работает, когда вы, наконец, нажмете на центральное репо. Если их это не устраивает, пока вы используете git (или очереди патчей для hg , IIRC), вы все равно можете использовать dev в том же стиле,

The big benefit of using a DVCS for me is that I can commit to my local repository without having to share these changes with everyone else. So when working on a big change I do small incremental commits, meaning I can revert just the last 30 minutes work, or do a diff against a version that was working yesterday, but then only push to the central repository once all my work is complete.

I think this benefit alone is worth moving to a DVCS for.

However, using a DVCS does require a little more thought and understanding and using a "standard" version control system like SVN or CVS so you will need to consider the training overhead if moving to a DVCS or your central repository will end up full of a lot different branches people didn't realise they were creating.

Здесь скоро начнется неизбежная война Git против Mercurial ... :-) Я лично использую Mercurial, но то, что я должен сказать, должно подходить для все DVCS.

На мой взгляд, да, они подходят для корпоративного использования. Я использую их в своей компании, хотя и с небольшим количеством разработчиков, но если вы беспокоитесь о масштабируемости, посмотрите на большие проекты с открытым исходным кодом, использующие git и mercurial, например Mozilla, Python.

Центральный хаб подход работает хорошо - это знакомая рабочая модель пользователям Subversion, и у вас всегда есть «окончательная» версия. Заблокируйте доступ к этому и примените любые хуки для обеспечения соблюдения политик фиксации, и после этого разработчики имеют большую свободу действий, как им нравится, со своими локальными копиями.

Еще одним большим плюсом является то, что я ' Мне показалось, что слияние с mercurial гораздо менее болезненно, чем с subversion.

Что сложнее с DVCS, так это управление двоичными файлами - вы не можете требовать блокировки двоичного файла, как вы можете это сделать с subversion (среди прочего). В идеале управляйте этим с помощью связи.

Наконец, клонирование репо отлично подходит для синхронизации проверок, если вы работаете с нескольких компьютеров.

Надеюсь, это поможет. K

Я думаю, что основное преимущество DVCS проявляется в том, что вы хотите передать свои изменения напрямую другим людям (или машинам, например, забрать репозиторий с собой домой), без использования центрального концентратора. Если у вас есть необходимость в этом, DVCS определенно лучший вариант. Если, как вы говорите,

все, что вы делаете с DVCS, - это создание центрального концентратора, в который все отправляют свои изменения в

, то вы на самом деле не пользуетесь преимуществом основной цели DVCS, и я бы сказал, что SVN

PS

Даже с рабочим процессом концентратора, DVCS дает вам возможность делать небольшие коммиты локально, объединять их только тогда, когда вы хотите, и отправлять их, когда они будут готовы.

С non -DVCS, вы вынуждены либо:

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

И если вы исследуете тупик, без DVCS: с первым методом вы не можете перемотать назад, у вас нет фиксации, к которой нужно вернуться; со вторым, и ваши коммиты, и их откаты должны были быть бессмысленно объединены всеми остальными.

накладные расходы не так велики, на самом деле, в нашей среде, добавленный hg push меньше накладных расходов, чем фиксация в центральном репозитории svn. но самый большой плюс - это все навороты, которые поставляются с Mercurial, которые отлично подходят для отдельного разработчика, независимо от размера команды или рабочего процесса. Прежде всего, замечательно то, что каждый wc является репо, так как вы можете гораздо более свободно экспериментировать, не загрязняя главное репо. то есть функциональность, основанная на равенстве wc == repo:

Базарная ВКС может работать как распределенная ВКС, так и как централизованная ВКС, поэтому у вас есть свобода выбора необходимого вам рабочего процесса. В то же время местные частные филиалы (где люди могут экспериментировать, работая над новыми функциями, и в то же время регулярно фиксировать их прогресс) приносят огромную пользу .

Также DVCS делает естественный рабочий процесс разработки, когда обязательный просмотр кода, требуемый до того, как новые изменения будут приземлены в ствол. Этот рабочий процесс (относительно SVN) блестяще описан в статье UQDS. И несмотря на то, что в статье описан рабочий процесс на основе SVN, вы найдете его более естественным, когда используете любую DVCS вместо SVN, потому что в DVCS разветвление и слияние является базовой первоклассной операцией.

Лично я считаю, что наибольшим преимуществом DVCS является то, что вы совершаете коммит (локально) перед слиянием, так что если на полпути слияние окажется более сложным, чем вы думали изначально, то тривиально вернуться в чистое состояние без потери работы. сравнить с CVCS, где вы обычно должны успешно слиять, прежде чем вы сможете совершить коммит.

дополнительные преимущества включают в себя:

• работа дома/на сайте клиента становится проще, так как вам не нужно подключение к сети только для того, чтобы что-то проверить, и если вы подождете до тех пор, пока вы не вернетесь на базу, чтобы нажать на изменения, история сохраняется, а не сваливает все в одно изменение.
• Большинство операций DVCS на самом деле намного быстрее, так как им не нужно перетягивать данные по сети
• Некоторые вещи (например, сценарии пользовательских настроек) лучше разделить непосредственно между разработчиками, которые хотят ими поделиться, а не через центральное место

По моему опыту, есть несколько способов использования DVCS в корпоративной среде:

• Поддержка нескольких сайтов: вы разделили команды и используете ваш DVCS для установки разных «серверов» в каждом месте, чтобы они не были ограничены основными сетевыми проблемами (и поверьте мне, они будут). Раньше это делалось с «большими вещами», такими как Clearcase Multi-site или Wandisco (для SVN / CVS), но теперь это вполне выполнимо с системами DVCS.

• Поддержка «роуминговых пользователей»: вы корпорация. разработчик, но вы хотите работать дома в течение определенного времени (или когда-либо): вместо того, чтобы полагаться на VPN, у вас может быть DVCS на вашем ноутбуке, и тогда вы можете делать коммит, просматривать, сравнивать, разветвлять и объединять без замедления вниз центральным сервером. Вы выполняете синхронизацию, когда находитесь в сети или снова в офисе.

• Истинная «распределенная разработка»: это крайний случай: каждый разработчик имеет свою собственную DVCS (как в мире OSS). На самом деле это будет зависеть от навыков и мотивации команды: если команда действительно хочет перейти в нее, они выиграют, в противном случае для SYSADM будет кошмаром иметь дело не с одним репо, а с сотнями ... с соответствующими проблемами.