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

Question

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

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

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

Я никогда не использовал хранилище для более чем одного проекта, но после прочтения: One svn repository or many? я я решил создать единый репозиторий для всех моих случайных школьных проектов.

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

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/

Является ли это то, что вы мульти-проект-в-одном-репо люди?

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/Магистральные
Repository/Project1/Метки
Repository/Проект1/Отрасли

Repository/Проект2/Магистральные
Repository/project2/Метки
Repository/project2/Отрасли

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

Реальный пример: проекты Apache repository.

Answer 6

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

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

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

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

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