Я искал и не смог найти никаких деловых причин, почему системы git / mercurial / bazzr лучше, чем централизованные системы (subversion, performance).

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

Вскоре я передам git своему менеджеру, это займет некоторое время на конвертирование репозиториев Subversion и некоторые расходы на покупку лицензий smartgit.

Редактировать Я попытался сделать этот вопрос в общую дискуссию по централизованному против децентрализовано, но неизбежно он превратился в мерзавец против подрывной деятельности. Конечно, есть лучшие централизованные системы, чем Subversion.

Хм, будучи менеджером, у меня есть две немедленные реакции "коленного рефлекса" на это:

• Если у вас нет веских причин, почему вы предлагаете что-то еще, кроме того, чтобы быть модным?
• Точно так же, как Subversion терпит неудачу так, что вам нужна замена?

На самом деле я не являюсь негативом - я думаю, что, вероятно, есть смысл, который нужно сделать (зависит от обстоятельств), но если дело просто в том, что git «лучше», чем subversion, то у вас его на самом деле нет.

Вы также должны быть в состоянии перечислить недостатки - вы уже определили издержки миграции и повторного набора инструментов - что еще является проблемой? Например, что происходит с вашим хорошим центральным резервным хранилищем? Как вы интегрируетесь с вашим сервером непрерывной интеграции (если у вас его нет, забудьте git и сначала разберитесь с ним). О безопасности и слежении - SVN работает с соответствующими логинами и разрешениями.

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

Может случиться так, что все, что вы хотите сделать, это запустить git локально на своей машине как «лучший» клиент Subversion (я смотрю на это с помощью Mercurial).

Хм, может быть, весь этот ответ на самом деле комментарий? Вы должны изложить свое мнение здесь (в вопросе) для git over subversion (в вашей среде), чтобы узнать, можем ли мы помочь вам определить экономическое обоснование.

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

Я бы сказал, что быстрое и безболезненное ветвление и слияние позволят разработчикам более продуктивно работать со своим кодом, поскольку каждая новая функция может быть разветвлена, а затем объединена. Заставить процесс разработки идти намного более гладко. Кроме того, распределенная природа позволила бы каждому разработчику иметь полную копию кода, поэтому не стоит беспокоиться о сбое централизованного сервера, что приведет к удалению всего вашего кода. Вероятно, есть и другие причины, однако эти две являются моими основными причинами использования Git.

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

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

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

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

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

• Почему совет должен всегда компилироваться
• Почему DVCS обеспечивает лучший центральный контроль
• Почему ветвление лучше с DVCS
• Почему распределенные модели ветвления могут плохо работать на вашем CVCS .

Не стесняйтесь понижать голосование, если вы не находите их уместными.

В двух словах, DVCS упрощает модели ветвления, которые могут помешать большим группам разработчиков наступать друг другу на ноги, что повышает как производительность, так и качество вашей ежедневной сборки. Беспорядочную совместную работу по управлению версиями можно выполнять в локальных репозиториях, что делает ваш центральный репозиторий более чистым и более качественным. Кроме того, решения о том, когда переходить, могут иметь большое влияние на эффективность, например, если один отдел готов начать работу над 2.0, когда 1.0 все еще очищается другими. DVCS позволяет принимать эти решения на местном уровне, а не комитетом.

Мои аргументы в пользу DVCS таковы:

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

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

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

По сути, речь идет о снижении трения. Для этого есть термин: муда . Чем больше трения, тем больше боли это делать. Чем больше боли, тем меньше делается, тем меньше прибыли.

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

SVN делает жизнь разработчиков несчастной . И это делает бизнес программного обеспечения несчастным.

... способами, которые многие не осознают, пока не начнут использовать DVCS. Это самое важное экономическое обоснование, которое может быть сделано . Зачем? Что ж, по сравнению со стоимостью поиска и удержания хороших разработчиков стоимость перехода на DVCS практически не существует .

Учтите следующее:

• Все операции, кроме самых простых в SVN (и большинстве других CVCS), требуют доступа к сети. В большинстве DVCS доступ к сети происходит только при выполнении операции pushили pullоперации. Это означает, что нетривиальные команды работают медленно . Что вы делаете, когда команда принимает навсегда? Я лично захожу на сайт programmers.se или хакерские новости, пока жду. Проще говоря, DVCS позволяют программистам сосредоточиться на том, что они любят: написание программного обеспечения компании .
• SVN поддерживает ветвление во многом таким же образом, как в тюрьмах есть возможность бросать мыло в душ: вы можете это делать, но когда вы это делаете, вас трахают. Таким образом, SVN заставляет ваших разработчиков постоянно бороться друг с другом за внесение изменений .
• Когда SVN не работает, он не работает. Разработчикам становится очень трудно выполнять свою работу, если они вообще могут ее выполнять. Таким образом, SVN заставляет ваших разработчиков полагаться на то, что ваша инфраструктура на 100% не содержит ошибок .
• В наши дни git быстро завоевывает популярность, а SVN быстро теряет его. Если использование DVCS по сравнению с SVN не дает никаких преимуществ, почему сообщество программистов меняется так быстро, как только может?

Что все это значит? Я еще не встречал разработчика, который дал честную попытку DVCS, который впоследствии предпочел бы SVN. Если бы я мог сделать еще одно раздражающее, смелое утверждение, SVN - это «необходимое зло», которое разработчики заставляют себя использовать. Git - это инструмент, который делает разработчиков более продуктивными и счастливыми .

(Я должен отметить, что выделенные жирным шрифтом выражения являются именно теми, на которых вы должны сосредоточиться. Остальные из них просто предоставляют контекст.)

Единственное, о чем я могу думать, это то, что git работает без сетевого подключения. Все остальное даже часто трудно продать техническим пользователям, которые используют суберсию или работу в течение достаточно долгого времени.

Разница показывает, когда есть проблемы

Мы перешли на git 6 месяцев назад после портирования нашего десятилетнего репозитория.

До сих пор, после небольшого эксперимента, я нашел следующее:

• ветвление и слияние практически безболезненно. Это значительно облегчает работу с отдельными функциями и исправление ошибок, не наступая друг другу на пальцы. Это также позволяет очень легко применить данное исправление в другом месте.

• более надежный дизайн - вы не полагаетесь на доступность центрального сервера на 100%, а если это не так, вы можете временно рекламировать любой клон в качестве горячей замены. Это устраняет критическую точку отказа - если сервер SVN выходит из строя по какой-либо причине, никто не может выполнять работу SVN. Если по какой-либо причине центральный репозиторий git выходит из строя, вы все равно можете работать и выполнять push / pull локально, чтобы гарантировать репликацию коммитов. Вы даже можете иметь несколько сторонних репозиториев именно для этой цели.

• взаимодействие с хранилищем упрощено. Для CVS вам по сути нужен доступ все время, когда вам нужна какая-то часть информации. Для git локально доступен весь репозиторий, что позволяет многим вещам идти быстрее.

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

Следовательно, я предлагаю, чтобы в вашем экономическом обосновании было то, что вы будете делать, когда случится беда ...

Простота ветвления и слияния - самая конкретная причина, но чтобы убедить кого-то, вам нужно будет привести конкретный пример того, как это улучшает ситуацию.

Допустим, у вас есть несколько программистов, работающих над улучшением производительности приложения, и они находятся на экспериментальной стадии и не знают, будет ли когда-либо написанный ими код частью ветки master / trunk. Однако им нужно часто обмениваться кодом друг с другом и опробовать идеи, которые могут оказаться в тупике. Как вы справляетесь с такими частыми ветвлениями и слиянием в Subversion? Короткий ответ: вы этого не делаете. С dvcs это действительно легко, и программисты могут быстро опробовать новые идеи в ветках и поделиться с другими, прежде чем решить, будет ли эта идея реализована.

Бизнес-аргумент в пользу прекращения использования SubVersion - поддержка ветвления, препятствующая стабилизации и обслуживанию продукта. Если вам нужно выпустить продукт, а затем продолжить разработку, вам нужна ветка. С помощью Subversion разработчики не будут правильно использовать ветвление, и поэтому вы не сможете продолжать разработку в транке, и убедитесь, что исправления ошибок действительно внесут это как в ствол, так и в ветвь.