Структура папок для многих проектов в одном репозитории SVN?
Не могли бы вы опубликовать свой компонент ScreenOne и ScreenTwo? проверьте, обернуты ли эти 2 компонента тегом Page
5 ответов
У Вас есть две опции для этого. Тот, который Вы уже упомянули, и это должно иметь соединительную линию для каждого проекта (опция 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 желательна, если все проекты развертываются вместе. Это вызвано тем, что только необходимо отметить репозиторий однажды при развертывании.
, Так как Вы используете Подверсию для школьных проектов, необходимо спросить себя, необходимо ли будет когда-либо отмечать работу. Можно также спросить себя, необходимо ли когда-нибудь создавать ответвления (Вы, вероятно, хотели бы к тому, если Вы хотите экспериментировать немного). Необходимо будет также спросить себя, рады ли Вы перейти ВСЯ своя работа вместе как один, того, предпочитаете ли Вы гибкость ветвления каждого проекта независимо.
эмпирическое правило, за которым я всегда следую: соедините магистралью вместе независимо от того, что мы развертываемся вместе.
(По тому, как - у Вас может быть много соединительных линий в том же репозитории - это почти эквивалентно наличию одной соединительной линии в нескольких репозиториях, за исключением того, что каждый репозиторий поддерживает свой собственный счетчик пересмотра и Вы не можете объединиться между репозиториями.)
Это - то, что я использую для своего домашнего управления исходным кодом.
, Где у меня только есть одно первичное хранилище.
Repository/Project1/Trunk
Repository/Project1/Tags
Repository/Project1/BranchesRepository/Project2/Trunk
Repository/Project2/Tags
Repository/Project2/Branches
мне нравится эта структура, очень легко сослаться на проекты и поддержать целостность.
Если Вы настаиваете на том, чтобы иметь всего один репозиторий (я нахожусь в не лагерь сам), и сделайте ветвление затем, я думаю, что Вы предлагаете, хорошо. Но снова, я полагаю, что репозиторий SVN равен проекту.
Нет никакого четкого ответа на этот вопрос, поскольку он зависит от того, что удовлетворяет Вашим проектам лучше всего.
- я использовал бы/projectA/trunk расположение, если бы была любой тяжелая разработка, продолжающаяся на проект, и все должно быть разделено, так как нет так большого соединения между ним (компоненты/проекты что одинокое). Однако Вы могли также использовать один репозиторий SVN на проект затем. Помните, что Вы не сможете проверить все проекты с помощью svn co http://..../svn/, потому что это также выбрало бы все теги и ответвления из всех проектов, не только соединило бы магистралью.
- /trunk/projectA, конечно, был бы лучше, если Ваши проекты/компоненты принадлежат плотно вместе, и необходимо отметить и перейти их от того же пересмотра (как библиотека, принадлежащая очень тесно основному проекту). Можно также использовать svn co http://.../svn/trunk/ для получения всех проектов на их последнем магистральном пересмотре, если Вам нравится.
С точки зрения пригодности для обслуживания я почти всегда предпочитал бы второй путь; но если бы Ваши проекты становятся больше и могли бы продлить, было бы лучше использовать отдельные репозитории на проект.
Помимо этого: проверьте, нужны ли Вам действительно сервисы Google Code для Вашей домашней работы, потому что ее цель состоит в том, чтобы поддерживать OSS. Можно всегда использовать SVN локально или даже через SSH, таким образом, Вы могли также поместить свои репозитории на карту с интерфейсом USB или некоторый компьютер, к которому можно получить доступ удаленно; Вам действительно не нужен хостинг для этого. Могли также быть проблемы конфиденциальности.