Нужны ссылки на макет репозитория

Я предвижу битву за репозитории Subversion: в настоящее время у нас есть одно веб-приложение, которое было зарегистрировано как 3 основных проекта и 2 проекта отчетов (когда я начинал 6 месяцев назад), сейчас до 7 проектов, и ожидается, что он будет расти дальше .

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

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


repository svn design-principles
person orbfish    schedule 21.12.2010    source источник
comment
Вы имеете в виду, что у вас есть несколько репозиториев для кода, который вы описали выше?   -  person Sander Rijken    schedule 21.12.2010
comment
Я думаю, имеется в виду, что в одном репо 7 приложений. возможно, например, / trunk / project_1, / trunk / project_2, ...   -  person EnabrenTane    schedule 21.12.2010
comment
это то, что я тоже читал. Я думал, что создание / trunk / goober / project_x будет означать, что вы можете зафиксировать в goober, чтобы сразу улавливать все изменения, связанные с функцией в различных проектах.   -  person jaydel    schedule 21.12.2010
comment
@EnabrenTane: Это явно не 7 отдельных приложений, поскольку вопрос жалуется на невозможность выполнить одну проверку для одной функции.   -  person Phil Miller    schedule 21.12.2010
comment
@Sander - да, несколько репозиториев. Шокирует, не так ли? @EnabrenTane - нет, все одно приложение.   -  person orbfish    schedule 22.12.2010

Ответы (2)


arrow_upward
0
arrow_downward

В Subversion есть множество вариантов структурирования вашего репозитория. См. обсуждение макета репозитория в документации.

Обычно я следую этим правилам:

  • Что-то другой проект, без дублирования, не те же пользователи или группы? ==> Вы можете использовать разные репозитории (но не обязаны это делать.
  • Существуют ли независимые части, которые будут отслеживаться и строиться независимо друг от друга? ==> Используйте так называемый «многопроектный макет» (см. Ниже).
  • Если вы разрабатываете одно приложение и в нем работают разные команды, используйте так называемый «single-project-layout».

Разница в следующем:

  • Схема единого проекта:

     Repo MyProject:
 trunk/
   java/
     src/
   ruby/
   doc/
   ...
 tags/
   rel1.0/
     java (references the copy of java of revision xxx)
     ruby (references the copy of ruby of revision xxx)
     ...
   rel1.1/
     ...
 branches/
   feature_x/
     java (references the copy of java of revision yyy)
     ...

  • Макет для нескольких проектов:

     Repo MyProjectBundle:
 proj1/
   trunk/
     java/
       src/
   tags/
     rel1.0/
       java (references the copy of java of revision xxx)
       ...
     rel1.1/
       ...
   branches/
     feature_x/
       ...
 proj2/
   trunk/
   tags/
   branches/
 ...

Итак, основные отличия заключаются в следующем:

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

В качестве справки у меня есть только цитируемая красная книга SVN и, конечно же, один из многих ответов в stackoverflow: Репозиторий Subversion Макет

person mliebelt    schedule 28.09.2011

arrow_upward
-1
arrow_downward

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

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

Cripes, надеюсь, я ответил на ваш вопрос хотя бы частично.

person jaydel    schedule 21.12.2010
comment
Это мой аргумент, но он был разработан с использованием 7 каталогов верхнего уровня, и это то, что я пытаюсь изменить. У меня вопрос, как я могу доказать, что это плохо, плохо, плохо? - person orbfish; 22.12.2010