Как правильно хранить общий код, используя CVS или SVN с командой

Question

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

Я пытаюсь убедить моего босса позволить нам начать все с нуля и сделать все правильно. Вот мой вопрос:

Как вы храните проекты, чтобы новый человек мог легко прийти и написать код, но при этом найти место для общего кода?

Например, мы должны хранить наш код следующим образом:

/repo
  /project1
  /project2
  /common (contains db connection classes, etc)

Теперь я хочу добавить новый проект. Должен ли я создать свой новый проект и взять то, что находится в общем каталоге, скопировать и вставить его в мой новый проект, а затем загрузить весь этот проект как /project3, чтобы, если появятся новые ребята, он мог просто проверить project3 и все, или я должен создать свой новый проект, и большая часть его связана с / project3 в CVS, а затем мои общие материалы связаны с / common в CVS? Теперь проблема в том, что, если приходит новый парень, он должен потратить дни, пытаясь выяснить, где весь код проекта 3 находится в репо

Answer 1

Есть несколько способов справиться с общими вещами.Один из них - скопировать его в хранилище.Это технически известно как The Stinky Bad Way .Причина довольно проста: если вы меняете модуль common для одного места, но не делаете это в других местах.Через некоторое время у вас больше не будет общих .

В Subversion вы можете использовать svn: externals для автоматического импорта общий код в каталогах.Технически это называется В зависимости от запатентованного механизма управления кодом, который работает не так хорошо .Я пытался использовать svn:externals в течение многих лет, и никогда не работал так, как я хочу.Проблема в том, что когда я отмечаю мой код или создаю ветку, мои ссылки svn: external не перемещаются автоматически.

Например, представьте, что я зависим от общего проекта, хранящегося вhttp://repos/svn/common.Поскольку в моем проекте требуются общие изменения, мы решили создать общую ветку 2.1 в http://repos/svn/common/branches/2.1, и мой svn:externals укажет на это.После того, как я закончу вносить изменения, я сначала должен создать тег http://repos/svn/common/ tags /2.0 в общем достоянии, затем я должен изменить свой svn:external, чтобы он указывал на этот новый URL, а затем, наконец, создать свойтег в моем проекте.И, если я буду зависеть от десятков общих проектов, я буду отслеживать десятки этих внешних объектов.

Лучший способ - это рассматривать ваши общие зависимости как предварительно скомпилированные сторонние библиотеки.Если вы используете Java, они станут .jar файлами.Если вы используете C ++, они станут *.so или *.dll.Затем вы сохраняете эти скомпилированные объекты в репозитории релизов, и во время процесса сборки вы можете выбрать правильную версию этих зависимостей в каждом проекте.

Хорошая новость заключается в том, что уже существует надежная технология с открытым исходным кодом, котораяделает это, так что вам не нужно ничего придумывать.Плохая новость заключается в том, что это Maven.

Однако, даже если вы не магазин Java, или вы используете Ant вместо Maven, вы все равно можете использовать тот же механизм, который Maven использует, чтобы вытащить свой общий пре.-компилированные зависимости.

Вам необходимо использовать программный пакет репозитория Maven, например Nexus или Artifactory .Если вы не являетесь магазином Java, вы не подключаете эти репозитории к внешнему миру.Просто используйте их для хранения своих выпусков.

В процессе сборки вы загружаете зависимости, используя либо стандартный wget или curl, либо Ivy, если вы используете Ant, либо если вы используете Maven, Mavenобрабатывает это автоматически.

Чтобы загрузить артефакты во время сборки, вы можете использовать плагин Maven deploy:deploy-file.

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

---

Ответ Робу Нейперу

+ 1 для отличного обсуждения, но предупреждение: использование предварительно собранногоОбъектные файлы очень сложны, когда все части разрабатываются одновременно.Это хорошо работает, когда эти файлы .jar / .so / .dll достаточно стабильны и статичны, и в некоторой степени, когда их поддерживают специальные группы.Но если вы разрабатываете все части вместе, и ваша команда не решительно настроена на повторное использование, мой опыт показывает, что Stinky Bad Way - это то, что по-прежнему работает лучше всего для кода, который сильно меняется.Облегчите лучшее повторное использование с частями, которые очень редко меняются, а затем расширяйте повторное использование по мере того, как вы учитесь и взрослеете.- Роб Нейпир

Sticky Bad Way (SBW) - самый простой способ сделать компоненты. Это особенно верно, если вы создаете свой компонентный код во время создания программ, которые используют этот код. Проблема в том, что написание исходной программы занимает всего 10% от программирования. Остальные 90% поддерживают эту программу и следят за тем, чтобы она оставалась актуальной. Это самая сложная часть программирования.

Представьте себе, если я решу использовать сервис Amazon S3 для хранения, и я напишу то, что вы могли бы назвать API или драйвером для работы между моей программой и S3. Допустим, вы называете его Пакет Foundation , и все ваши программы будут его использовать.

Самое простое, что нужно сделать - это SBW - просто скопируйте код Foundation в каждый модуль. Если есть проблема или модуль нуждается в новой функции, которой нет в Foundation , я могу просто изменить Foundation, пока он не сделает то, что я хочу.

Это отлично работает в течение нескольких лет. Затем Amazon объявляет о новом API, и этот старый API устареет. Мало того, новый API имеет функции, которые нужны вашим клиентам. Теперь у вас есть проблема.

У вас есть эта проблема, потому что у этого Foundation нет реального владельца. Отдельные команды разработчиков никогда не занимали время, чтобы изучить код. Если произошли изменения, они использовали метод развития HAIUIW ¹ . Теперь у вас есть полдюжины отдельных и несовместимых Foundation модулей, которые никто на самом деле не понимает.

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

В программировании 10% включают в себя написание этого первого бита кода. Остальные 90% пытаются сохранить этот код. Мы давно узнали, что мы пытаемся найти ошибки как можно раньше, когда мы кодируем. Во многих парадигмах программирования мы учимся сначала писать тесты и документацию, а затем код. Это сложно и не весело. Это делает первые 10% действительно очень сложными. Я мог бы написать это через пару дней, но теперь я провожу пару недель, делая все это , думая .

Тем не менее, мы знаем, что это значительно облегчает выполнение остальных 90% нашей работы по программированию. То же самое относится и к компонентам. Это так легко скопировать код из одного места в другое и HAIUIT. Гораздо сложнее создать отдельный компонент с собственной командой. Эта команда должна работать с другими командами разработчиков. Будут споры, конфликты и крики спичек. Люди будут называть друг друга именами. У каждой группы свои цели. Теперь представьте, что вы делаете это, пытаясь настроить репозиторий релизов и создать всю инфраструктуру, чтобы все заработало. Эти первые 10% действительно сложно сделать.

Но когда Amazon делает это объявление для своего нового API, или вы обнаружите, что вы могли бы значительно увеличить продажи, если бы вы могли заставить свое программное обеспечение работать и с Microsoft Azure, делая этот отдельный компонент намного проще, а остальные 90% - гораздо проще. .

---

¹ Хак, пока он не работает.

Answer 2

Во-первых, я настоятельно не рекомендую все, что включает в себя «давайте начнем с нуля и сделаем все правильно». В подавляющем большинстве случаев лучше выбрать новое направление и со временем мигрировать к нему. Это требует определенных обязательств со стороны команды, но все повторное использование кода требует обязательств со стороны команды.

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

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

Это ведет вас к клонированию общего кода для каждого проекта, который быстро разветвляет общий код, делая его вовсе не «общим». Так что же делать команде?

Первый шаг - полная честность с собой и своей командой. Ваша команда на самом деле стремится к повторному использованию кода? Это не может быть один или два парня. Это должна быть команда, включая менеджера. Никакой процесс не изменит вашу культуру. Вы не можете просто сказать «мы будем повторно использовать код, потому что у нас есть » и ожидать, что это произойдет. Ничего не происходит таким образом.

Вместо этого я рекомендую брать легкие выигрыши, поскольку вы можете их получить. Определите, что является общим, а внутри того, что действительно стабильно и редко меняется. Это то, что нужно объединить. Для SVN используйте svn: external для этого, чтобы одна проверка получила все (svn: external - большая проблема, если код сильно меняется, но мы договорились выше, что это код, который редко изменяется). Для CVS переключитесь на SVN. : D В CVS вас могут заставить создать скрипт "checkout-зависимости" в верхней части каталога проекта. Я ненавижу их, но если они последовательны, то это не самое худшее решение. Действительно стабильный код может быть зарегистрирован как библиотека, чтобы ускорить время сборки.

Материал, который сильно изменится, и вы не намерены поддерживать общий доступ, клонируйте его в проекты. В идеале вы должны говорить между проектами о том, что вы можете интегрировать исправления, выбирать новые версии друг от друга и т. Д. Если вы не общаетесь друг с другом, тогда общий код будет разветвляться. (Но если вы даже не можете разговаривать друг с другом в неформальной обстановке, то если вы поместите все это в один каталог, это не заставит вас говорить. Это просто вызовет взрыв.)

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

Но независимо от того, каким путем вы идете, ваше внутреннее чувство, что разработчики должны иметь возможность просто «оформить заказ, собрать, запустить», не читая три вики-страницы и не спросив шесть человек, абсолютно правильно. Это важно для ИМО.

Answer 3

Используйте svn: externals для проверки общего кода вместе с проектом, который требует этого. У вас могут быть разные версии вашего общего кода, поэтому вы, вероятно, захотите пометить его и использовать внешний для ссылки на помеченную версию.

Установить свойство: svn:externals common http://your.svn.provider/repo/common на каждом из ваших проектов. Это приведет к тому, что общее будет проверено с проектом.

Answer 4

1. Перейти к SVN
2. От «одного репо - многие проекты» переходят к парадигме «репозиторий на проект» - это требует больше управленческой работы, но
   • Ревизии в SVN являются глобальными в репозитории, а не в файле: в случае одного проекта вы получите линейную историю ревизий без дырок (как это происходит в случае нескольких независимых проектов в репо)
   • Репо-хуки также являются глобальными, и если у вас есть несколько проектов в одном репо, это будет стоить дополнительной логики внутри кода хука (какие действия необходимо выполнить для каждого проекта)
3. Как уже было предложено, используйте svn: externals для общего повторно используемого кода, но - всегда определяйте явные номера ревизий во всех ваших определениях внешних ссылок .

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

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

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

Это также означает, что вы можете устранить чрезмерную пометку кода в вашем внешнем репозитории и сэкономить некоторое время