Система контроля версий для не очень умных программистов

Question

Проблема :

Огромная база кода, охватывающая несколько миллионов SLoC, поддерживаемая (поддержка / активные улучшения и т. Д.) Множеством программистов второго / третьего уровня (большинствоте, кому на самом деле все равно).Несколько десятилетий назад немногие умные парни создали оболочку, которая использует CVS, и эта система используется нынешним поколением разработчиков (90% из них не использовали CVS напрямую или слышали о / использовали другую систему управления исходным кодом из командной строки).

Эффект :

Использование CVS и нескольких групп, работающих в нескольких модулях, неизбежно => Объединение веток CVS в багажник.Это было бы занятием, осуществляемым наиболее религиозно и ритуально возможным способом.[=> грубая сила;запланированные недели вперед, с участием дюжины парней на 2/4 дня.Сотни (иногда тысячи) источников обрабатываются вручную. Самое забавное, что вовлеченные люди не являются первоначальными владельцами исправления, и они просто проверяют различия;на самом деле, не шучу! ] Это приводит к серии несогласованности в здравом уме библиотек / модулей / функций, и слишком много усилий затрачивается на исправление дефектов из-за регрессии во время этих слияний.

А теперь вопрос:

Какая альтернативная система контроля версий может внести некоторые позитивные изменения и улучшить жизнь программистов / менеджеров икто-нибудь еще в окружении?

Поскольку все вокруг, кажется, выпили KoolAid (и поют "Это-как-то-то-делается-везде"), даже не задумываясь онайти альтернативу, давно пора это сделать.Но учитывая то, какие люди будут использовать систему, необходимо учитывать следующие аспекты.

1. Простой в использовании && понять, даже Джо Кодер должен иметь возможность использовать его без суеты.(В любом случае это не понадобится, поскольку обертка будет скрывать реальные вещи под капотом от людей)
2. A HUGE кодовая база (состоящая из источников на нескольких языках), с несколькими(около 30) активных веток в любой момент времени.
3. Легко сливается с различными ветками.(учитывая, что объем изменений довольно велик)
4. Коммерческая поддержка системы была бы приятной, если бы она была доступна.
5. Разработка происходит на серверах UNIX (Должна работать как минимум на HP-UX / Solaris)
6. Должен хорошо масштабироваться (тысячи пользователей / сотни тысяч источников)
7. Хорошая документация
8. Простой / понятный интерфейс на основе браузера для сравнения / просмотра изменений / копий.
9. В хранилище нет двоичных файлов, поэтому не нужно беспокоиться о них.
10. Положение для импорта текущего содержимого репозитория в новую систему.

Итак, пожалуйста, предложите.Есть ли надежда и есть выход?:) Я почти уверен, что такие вещи, как git, будут полностью отвергнуты (они считают, что "git предназначен только для умных людей")

EDIT: я тоже имею в виду Mercurial и BitKeeper и упомянулэто людям вверх по цепочке.Надеюсь на лучшее!Спасибо!:)

Answer 1

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

Answer 2

Mercurial будет моим предложением. Чтобы избежать «сложного» восприятия, взгляните на этот сайт .

Это «Дружественное введение в Mercurial DVCS от Джоэла Спольски», и оно предоставляет отличное учебное пособие для пользователей (и часть восстановления Subversion), в котором они шаг за шагом редактируют, фиксируют, объединяют и т. Д.

Answer 3

Я уверен, что такие вещи, как git, будут полностью отвергнуты (они считают, что "git предназначен только для умных людей")

Если это просто вопрос "восприятия" - они "воспринимают" git как слишкомСложно, попробуйте предложить Mercurial или Bazaar - они могут быть недостаточно знакомы с ними, чтобы сформировать неточное предубеждение.

Answer 4

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

Многие, многие люди сделали эту миграцию. Есть утилиты для переноса вашего кода из CVS в SVN (но не безболезненно).

Он должен соответствовать большинству ваших требований (хотя насколько простым может быть слияние, является спорным).

Итог: ваша задача не в технологии. Это принятие. Если ваша команда не хочет меняться, это не будет. И, к сожалению, любое решение будет обречено. Вы должны убедить их, что они должны измениться в первую очередь. Лучше всего обратиться к их лени (я имею в виду это позитивно) и показать, что «жизнь станет лучше», если они изменятся.

Answer 5

Любой инструмент требует обучения.Я бы сказал, что если вы уверены, что перейдете на какую-то другую систему, то имеет смысл потратить некоторое время на обучение ребят, чтобы в долгосрочной перспективе это было бы очень полезно.Посмотрев на ваш набор требований, я бы сказал, попробуйте посмотреть на SVN или SOS.Преимущество наличия SOS заключается в том, что вы получаете поддержку 24 * 7 по вопросам.Они могут обрабатывать большие данные.У них также есть классный интерфейс браузера.