Структура папок для многих проектов в одном хранилище SVN?

Question

Я только что создал Google Code SVN-репозиторий для хранения моих школьных проектов и домашних заданий, а также для простого переноса между школой и домом.

Его каталоги по умолчанию, которые он создает:

https://simucal -projects.googlecode.com / SVN / багажник /
https://simucal -projects.googlecode.com / СВН / теги /
https://simucal -projects.googlecode.com / svn / филиалы /

Я никогда не использовал репозиторий для более чем одного проекта, но после прочтения: Один SVN-репозиторий или несколько? Я решил создать один репозиторий для всех моих случайных школьных проектов. 1024 *

Должен ли я просто скопировать структуру папок выше, но для каждого проекта?

https://simucal -projects.googlecode.com / SVN / Projecta / багажник /
https://simucal -projects.googlecode.com / SVN / Projecta / теги /
https://simucal -projects.googlecode.com / svn / projectA / branch /

https://simucal -projects.googlecode.com / SVN / projectB / багажник /
https://simucal -projects.googlecode.com / SVN / projectB / теги /
https://simucal -projects.googlecode.com / svn / projectB / филиалов /

Это то, чем занимаются люди из нескольких проектов в репо?

Answer 1

У вас есть два варианта для этого. Тот, который вы уже упомянули, и который должен иметь транк для каждого проекта (вариант 1):

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

Вариант 2 будет иметь одну ствол с каждым проектом, являющимся подпапкой под стволом:

https://simucal-projects.googlecode.com/svn/trunk/projectA/
https://simucal-projects.googlecode.com/svn/tags/projectA/
https://simucal-projects.googlecode.com/svn/branches/projectA/

https://simucal-projects.googlecode.com/svn/trunk/projectB/
https://simucal-projects.googlecode.com/svn/tags/projectB/
https://simucal-projects.googlecode.com/svn/branches/projectB/

Преимущество варианта 1 состоит в том, что вы можете разветвлять и маркировать каждый проект независимо. Это желательно, если вам нужно развернуть каждый проект отдельно.

Вариант 2 желателен, если все проекты развернуты вместе. Это потому, что вам нужно пометить хранилище только один раз при развертывании.

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

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

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

Answer 2

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

Где у меня только один основной репозиторий.

Repository / Project1 / Trunk
Repository / Project1 / Метки
Repository / Проект1 / Филиалы

Repository / Проект2 / Trunk
Repository / Проект2 / Метки
Repository / project2 / Филиалы

Мне нравится эта структура, очень легко ссылаться на проекты и поддерживать целостность.

Answer 3

Реальный пример: хранилище Apache Projects .

Answer 4

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

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

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

И если мы хотим разрешить доступ каждого проекта к определенной группе пользователей, эта структура хороша:

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags

Answer 5

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

Answer 6

На этот вопрос нет однозначного ответа, поскольку это зависит от того, что лучше всего подходит для ваших проектов.

1. Я бы использовал макет / projectA / trunk, если в каждом проекте велась интенсивная разработка, и все должно быть разделено, поскольку между ними нет особой связи (компоненты / проекты, которые стоят отдельно). Однако вы можете также использовать один репозиторий SVN для каждого проекта. Помните, что вы не сможете проверить все проекты, используя svn co http: //..../svn/, поскольку это также приведет к извлечению всех тегов и веток из всех проектов, а не только транка.
2. / trunk / projectA, безусловно, было бы лучше, если бы ваши проекты / компоненты были тесно связаны друг с другом, и вам нужно пометить и разветвлять их из одной и той же ревизии (например, библиотеки, которая очень близко относится к основному проекту). Вы также можете использовать svn co http: //.../svn/trunk/, чтобы получить все проекты на их последней редакции транка, если хотите.

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

Кроме того: проверьте, действительно ли вам нужны сервисы Google Code для домашней работы, поскольку ее целью является поддержка OSS. Вы всегда можете использовать SVN локально или даже через SSH, поэтому вы также можете поместить свои репозитории на USB-накопитель или на некоторый компьютер, к которому можно получить удаленный доступ; вам не нужен хостинг для этого. Также могут быть проблемы с конфиденциальностью.