Структура проектов в управлении версиями

Я знаю, что есть как минимум 10 разных способов структурировать проект в системе контроля версий. Мне любопытно, какие методы используются и какие у вас работают. Я работал с SVN, TFS и в настоящее время / к сожалению VSS. Я видел, что управление версиями реализовано очень плохо и просто нормально, но никогда не получалось.

Просто, чтобы начать игру, вот обзор того, что я видел.

Этот пример основан на SVN, но применяется к большинству VCS (не столько к распределенному управлению версиями).

  1. ветвить отдельные проекты, которые являются частью сайта / подразделения / веб / имя_проекта / vb / src / [транк | филиалы | теги]

  2. Разветвите весь сайт, в случае, который я видел, весь сайт, за исключением основных компонентов, был разветвлен. / Деление / [ствол | ветви | теги] / Web / Projectname / VB / SRC /

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

19.08.2008 20:01:30
Пожалуйста, добавьте ярлык "svn", сбивающий с толку git-пользователей.
hhh 7.07.2012 02:32:10
@hhh Я добавил комментарий о распределенном контроле версий (DVC). Возможно, кому-нибудь будет полезен ответ о structur в DVC?
Greg Ogle 18.07.2012 16:39:42
9 ОТВЕТОВ

Пример для SVN:

хобот/

ветвь/

теги /

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

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

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

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

Изменить: Для сторонних вещей это зависит. Если я могу избежать этого, у меня нет контроля над исходным кодом. Я держу его в каталоге вне системы контроля версий и включаю оттуда. Для таких вещей, как jquery, я оставляю его под контролем исходного кода. Причина в том, что это упрощает мой скрипт для нажатия. Я могу просто сделать это сделать экспорт SVN и Rsync.

7
19.08.2008 20:30:32

Я думаю, что политики и процедуры SCM, которые принимает команда, будут сильно зависеть от процесса разработки, который они используют. Если у вас есть команда из 50 человек, в которой несколько человек работают над серьезными изменениями одновременно, а выпуски происходят только раз в 6 месяцев, для каждого имеет смысл иметь свою собственную ветку, где он может работать изолированно и объединять изменения только из другие люди, когда он хочет их. С другой стороны, если вы команда из 5 человек, все сидят в одной комнате, имеет смысл разветвляться гораздо реже.

Предполагая, что вы работаете в небольшой команде, где общение и сотрудничество хороши, а выпуски случаются часто, переход на IMO не имеет особого смысла. В одном проекте мы просто свернули номер редакции SVN в номер версии продукта для всех наших выпусков, и мы даже не пометили тегами. В редких случаях, когда в prod была обнаружена критическая ошибка, мы просто переходили прямо из выпущенной ревизии. Но большую часть времени мы просто исправляли ошибку в ветке и освобождали от ствола в конце недели, как и планировалось. Если ваши выпуски достаточно часты, вы почти никогда не столкнетесь с ошибкой, которая не может дождаться следующего официального выпуска.

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

Я также упомяну, что все, что я написал, исходит из корпоративного ИТ-контекста, где есть только один производственный экземпляр данной базы кода. Если бы я работал над продуктом, который был развернут на 100 различных клиентских сайтах, методы ветвления и тегирования должны были бы быть немного более напряженными, чтобы управлять всеми независимыми циклами обновления во всех экземплярах.

1
19.08.2008 20:24:52

А как насчет внешних зависимостей, таких как AJAXTookit или какое-либо другое стороннее расширение, которое используется в нескольких проектах?

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

1
19.08.2008 20:29:42

Для своих проектов я всегда использую эту структуру.

  • хобот
    • конфиг
    • документы
    • SQL
      • начальная
      • обновления
    • ЦСИ
      • приложение
      • контрольная работа
    • третье лицо
      • Lib
      • инструменты
  • теги
  • ветви
  • config - Используется для хранения шаблонов конфигурации моего приложения. В процессе сборки я беру эти шаблоны и заменяю токены-заполнители фактическими значениями в зависимости от того, какую конфигурацию я собираю.
  • документы - любая документация приложения размещается здесь.
  • Я делю свои сценарии SQL на две директории. Один для начальной настройки базы данных, когда вы начинаете заново, и другое место для моих сценариев обновления, которые запускаются на основе номера версии базы данных.
  • src - исходные файлы приложения. Здесь я разбиваю исходные файлы на основе приложения и тестов.
  • thirdparty - здесь я размещаю сторонние библиотеки, на которые я ссылаюсь, внутри своего приложения и недоступные в GAC. Я разделил их на основе библиотеки и инструментов. Каталог lib содержит библиотеки, которые необходимо включить в реальное приложение. Каталог tools содержит библиотеки, на которые ссылается мое приложение, но которые используются только для запуска модульных тестов и компиляции приложения.

Мой файл решения помещается прямо в директорию транка вместе с моими файлами сборки.

6
19.08.2008 20:39:42
как вы ветвитесь? если вы разветвляете только папку src, как вы обрабатываете ветку, указывающую на более старую версию третьей стороны / lib?
wal 28.08.2011 13:30:33

Мы практикуем высококомпонентную разработку с использованием Java, у нас есть около 250 модулей в транке, которые имеют независимые жизненные циклы. Зависимости управляются через Maven (это лучшая практика), каждая активно развивающаяся итерация (раз в две недели) помечается новой версией. Трехзначные номера версий со строгой семантикой (major.minor.build - значительные изменения означают обратную несовместимость, незначительные изменения означают обратную совместимость, а изменения номера сборки означают обратную и прямую совместимость). Наш конечный программный продукт представляет собой сборку, которая включает в себя десятки отдельных модулей, опять же как зависимости Maven.

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

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

Мы примерно делаем что-то вроде следующего:

svnrepo/
  trunk/
    modules/
      m1/ --> will result in jar file
      m2/
      ...
    assemblies/
      a1/
      ...
  tags/
    modules/
      m1/
        1.0.0/
        1.0.1/
        1.1.0/
       m2/
      ...
    assemblies/
      a1/
        iteration-55/
        ...
  branches/
    m1/
      1.0/
      ...

Что касается внешних зависимостей, я не могу переоценить что-то вроде Maven: управляйте своими зависимостями как ссылками на версионные, уникально идентифицированные двоичные артефакты в репозитории.

Для целостной структуры модуля / проекта: придерживайтесь стандарта. Однородность является ключевым. Опять же, Maven может помочь здесь, так как он диктует структуру. Многие структуры хороши, если вы придерживаетесь их.

10
24.06.2009 07:00:15
Есть ли что-то вроде maven, которое существует даже для .NET? Я не смог ничего раскопать.
whaley 15.06.2009 14:11:30
NMaven специально нацелен на .NET ( codeplex.com/nmaven ), сам не использовал его. На работе у нас есть .NET-код, созданный с использованием обычного Maven и некоторых плагинов для переноса в Visual Studio.
Boris Terzic 15.06.2009 20:12:01
Похоже, это хорошее начало, что мы начинаем новый проект со структурой, похожей на вашу :) Из любопытства, у вас есть общий родительский pom? Если это так, вы помещаете родительский pom в каталог «modules» или как фактический каталог внутри «modules»?
aberrant80 23.06.2009 08:25:50
У нас есть иерархия родительских компонентов, и мы относимся к ним так же, как к модулям: каждый из них имеет свой собственный каталог «module» внутри модулей. Начиная с Maven2, это, наконец, чисто возможно, так как родительские poms наследуются через репозиторий. В Maven1 вам действительно нужно использовать относительные пути, и это становится неприятным.
Boris Terzic 24.06.2009 06:59:36
Спасибо: D Еще один вопрос, если не возражаете. Мы должны были сделать переименование модуля прямо сейчас (неуместные начальные имена), и у нас есть небольшой аргумент. Если, скажем, ваша «trunk / modules / m1» должна быть переименована в «trunk / modules / m10», вы думаете, что «tags / modules / m1» следует переименовать в «tags / modules / m10» или must »теги / modules / m1 "будет сохранен и новые" теги / modules / m10 "будут созданы?
aberrant80 24.06.2009 10:37:36

Я могу оценить логику не помещать бинарные файлы в репозиторий, но я думаю, что есть и огромное преимущество. Если вы хотите иметь возможность извлечь конкретную ревизию из прошлого (обычно более старый тег), мне нравится иметь возможность получить все, что мне нужно, из проверки svn. Конечно, это не относится к Visual Studio или .NET Framework, но наличие правильной версии nant, nunit, log4net и т. Д. Позволяет действительно легко перейти от извлечения к сборке. Таким образом, начать работу так же просто, как «svn co project» и «nant build».

Одна вещь, которую мы делаем - это помещаем бинарные файлы ThirdParty в отдельное дерево и используем svn: external, чтобы получить нужную нам версию. Чтобы упростить жизнь, у нас будет папка для каждой использованной версии. Например, мы можем внести папку ThirdParty / Castle / v1.0.3 в текущий проект. Таким образом, все, что нужно для сборки / тестирования продукта, находится внутри или под корнем проекта. Наш опыт показывает, что обмен дисковым пространством того стоит.

2
19.08.2008 21:02:49

Мы мигрировали из плохого мира VSS с одним гигантским хранилищем (более 4G), прежде чем переключиться на SVN. Я действительно боролся с тем, как настроить новый репозиторий для нашей компании. Наша компания очень "старой" школы. Трудно добиться перемен. Я один из младших разработчиков и мне 45 лет! Я являюсь частью корпоративной команды разработчиков, которая работает над программами для ряда отделов нашей компании. Во всяком случае, я настроил наши каталоги, как это

+ devroot
    +--Dept1
        +--Dept1Proj1
        +--Dept2Proj2
    +--Dept2
        +--Dept2Proj1
    +--Tools
        +--Purchase3rdPartyTools
        +--NLog
        +--CustomBuiltLibrary

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

  • Трудно решить производственные проблемы, если вы работаете над серьезным обновлением продукта (т. Е. Потому что мы не делаем ветвления)
  • Сложно управлять концепцией продвижения из «Dev» в «Prod». (Даже не спрашивайте о продвижении в QA)
0
20.08.2008 02:59:28

Поскольку у нас есть все артефакты и конструкции в одном дереве, мы имеем что-то вроде:

  • Хобот

    • Планирование и отслеживание
    • Req
    • дизайн
    • строительство
      • мусорное ведро
      • База данных
      • Lib
      • Источник
  • Развертывание

  • контроль качества
  • Массачусетс
2
16.09.2008 14:48:24
Почему это было отмечено? Похоже на приличную структуру, даже если это не одна из стандартных версий, которые вы видите.
Nathan Palmer 5.09.2009 18:55:19

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

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

PAозначает пре-альфа A означает альфа B означает бета AR означает альфа-релиз BR означает бета-релиз RC означает релиз-кандидат ST означает стабильный

Существуют различия между сборками и выпусками .

  • Теги в папке builds имеют номер версии, соответствующий шаблону N.x.K, где Nи Kявляются целыми числами. Примеры: 1.x.0, 5.x.1,10.x.33
  • Метки под выпусками папки имеют номер версии , соответствующий шаблону N.M.K, где N, Mи Kявляются целыми числами. Примеры: 1.0.0, 5.3.1, 10.22.33.

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

Также есть мой ответ на вопрос «Несколько репозиториев SVN против репозитория одной компании». Это может быть полезно, если вы ответите на этот аспект структурирования репозитория в своем вопросе.

2
23.05.2017 11:45:56
Не могли бы вы обновить ссылку на диаграмму в первом абзаце?
FvD 22.06.2013 13:29:20