Плюсы и минусы распределенных систем контроля ревизий?

вопрос, на который указывает Себастьян, действительно имеет много хороших ответов,но позвольте мне рассказать вам о моем личном опыте. Я работаю с горсткой других людей, разбросанных по всей территории США, занимаясь, по сути, частной консалтинговой работой. Клиенты различаются по размеру, но наша команда небольшая, и мы работаем довольно быстро. Код является коммерческим, но принадлежит клиентам, когда мы закончим.

мы используем Mercurial, но конкретный инструмент менее важен, чем общий рабочий процесс использования распределенный контроль версий в отличие от централизованного. В моем опыте есть два большой преимущества производительности, без которых я больше не хочу работать:

1. прежде всего: ветвление и слияние легко. Это побочный эффект распределения, не строго требование, но это критично для DVCS, и я считаю это критичным для моей работы. Каждый из нас может свободно ветвить каждую функцию, над которой нам нужно работать ,заставить ее работать в песочнице (без вмешательство из нашего общего репозитория) и когда мы будем готовы объединить его обратно. "Идти в ногу" с изменениями других так же легко, как иногда сливаться, с возможностью отбросить слияние и продолжить, если решение конфликтов слишком много усилий в данный момент. Мы можем взять конкретные изменения и собрать их вместе в тестовой ветви, и сохранить результаты, если они нам нравятся, или бросить их, если нет. Эта способность пробовать вещи, делиться ими и сохранять только лучшие результаты-это серьезные пользу. Как я уже сказал, это не тот, без которого я могу комфортно работать на данный момент.
2. работа в автономном режиме. Это не звучит как большое дело, пока вы не работаете в своей обычной среде. Я могу поехать в отпуск, или путешествовать, или отключиться, или просто взять свой ноутбук на улицу в хороший день и продолжать работать. Психологическая польза от возможности вставать и уходить без необходимости прекращать работу или терять способность контролировать свою работу очень реальный.

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

У нас нет много жалоб. К этому нужно привыкнуть, хотя набор команд Mercurial достаточно близок к Subversion (который мы использовали), что у нас не было много проблем. Даже случайные гадости, такие как случайная проверка двоичных файлов или файлов, которые не следует проверять in, мы можем обойти, потому что мы можем воссоздать репозиторий без этих изменений и заменить наш основной, если нам нужно. Это не масштабируется до большой группы людей хорошо, но работает довольно хорошо для небольшой команды из 3-4 человек.

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

У меня есть особые проблемы с Mercurial (я действительно хочу, чтобы поддержка именованной ветви была просто мало немного проще) и с Git (я действительно хочу, чтобы набор команд был более интуитивным, даже сейчас), но они являются жалобами на угловые проблемы, которые приходят с большим знакомством. Они даже не были бы возможны, если бы эти инструменты не отодвинули оболочку того, что я думал, что VCS может сделать далеко за пределы того, что я знал, прежде чем начал использовать их.