2010-03-07 2 views
4

Мы использовали Google Code SVN для хранения школьного проекта. Поскольку мы экспериментировали с различными идеями, мы создали новые проекты Visual Studio и сохранили их там. Теперь мы хотим объединить все разные идеи в один окончательный проект.Google Code SVN Usage Advice

Вот текущий макет хранилища:

- svn 
- branches 
    - Idea1 
    - Idea2 
- tags 
- trunk 
    - Sub-Project1 
     - files (...) 
    - Sub-Project2 
     - files (...) 
    - Sub-Project3 
     - files (...) 

Я использую AnkhSVN вместе с Visual Studio, одна вещь, которую я заметил, что каждый раз, когда я проверка одного из проектов, каждый проект получает Выдана тоже (Я вижу это, когда смотрю на него через проводник Windows).

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

EDIT

Я не думаю, что я сделал хорошую работу, объясняя выше. Поэтому я снова иду.

Являются ли кодеки Google SVN-репозиториями настроенными для одного проекта? Или я могу использовать их для нескольких подпроектов? Причина, я прошу это структура файла SVN в пустой Google код проекта уже:

- svn 
- branches 
- tags 
- trunk 

Но я думаю, что каждый суб-проект будет нуждаться в этих трех компонентов.

Может быть, я был не ясен раньше, я переименовал части багажника (в подпроект) в приведенном выше списке. У каждого подпроекта есть уникальная цель. Дело в том, что я хочу объединить суб-проекты в более крупный проект.

+1

не собирается вам вообще помогать, но я думаю, что вы должны были использовать функциональные ветви с самого начала! Вы читали книгу «Красная бин»? –

+3

Лучшие практики SVN в Google Code в значительной степени такие же, как и в других местах. Работа с тегами. – MatrixFrog

ответ

2

Что бы я сделал это реорганизовать такие вещи, как так:

/svn 
    /Sub-Project1 
     /branches 
     /tags 
     /trunk 
    /Sub-Project2 
     /branches 
     /tags 
     /trunk 
    ... 

Вы можете сделать все это с помощью простых Svn ходов. Если ваши текущие ветви Idea1 и Idea2 имеют текущую über-тубу, тогда я могу переместить их на верхний уровень /oldtrunk/branches. Или просто удалите их, если они неактивны! Это svn, они все равно будут там. :)

Далее вы упомянули о желании «объединить суб-проекты», где каждый «имеет уникальную цель». Если вы хотите продолжать поддерживать их как полностью инкапсулированные подпроекты, я бы предложил создать их индивидуально и объединить их как библиотеки, а не комбинировать источник. В Java я бы использовал инструмент управления зависимостями, например Ivy, но я не уверен, какое лучшее решение для Google Code + Visual Studio. Вы можете использовать Ivy для не-Java-материалов, но это не так интуитивно.

1

Обратите внимание, что вы можете отрегулировать количество уровней вверх от местоположения файла решения AnkhSVN, выполняющего выезд. Он должен спросить, на каком уровне проект должен быть проверен при использовании File -> Open Subversion Project, и свойство еще не установлено. Вы также можете изменить его, используя File -> Subversion -> Change Source Control