Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > УП: Общие вопросы > SVN и структура проекта

Автор: chaos 14.1.2010, 10:53

Доброго времени суток! Прошу прощения если не туда запостил, мне показалось туда  К делу! Начинается новый проект. Проект не очень то и большой(~200 классов). Столкнулся с проблемой: как все это дело хранить в системе контроля версия(был выбран SVN) Краткое описание проекта: есть ядро(бэкенд и тп). будет 2 фронт енда. для одного фронтенда ядро будет браться в том виде в котором есть, а для второго существующее ядро как бы обернется в понятия чуть-чуть более высокого уровня, но без изменения самого ядра. с SVN не сильно дружу, тк в работал только с trank версиями проектов. по этому про ветки и тп мало чего знаю. Подскажите как мне правильно организовать хранилище? ЗЫ я себе картину представляю следующим образом: напишится ядро. создадутся две ветки frontend1 & frontend2 и там будет вестись вся работа.

Автор: maxim1000 14.1.2010, 11:38

чаще всего используется одна из двух структур: 1. root --trunk ----project1 ----project2 --branches ----branch1 ------project1 ------project2 ... 2. root --project1 ----trunk ----branches ------branch1 --project2 ----trunk ----branches ------branches1 выбирается та, которая более соответствует связанности проектов если у каждой из трёх частей будет свой цикл релизов, связность между ядром и фронт ендами небольшая, стоит выбрать вторую если все три куска кода будут представлять собой единое целое и релизиться одним куском, есть смысл выбрать первую структуру обнаружить неправильный выбор структуры очень просто - с ней будет неудобно работать (правда, к сожалению, многие начинают терпеть "объективные трудности", героически с ними бороться, писать всякие скрипты и полноценные приложения для создания веток, вместо того, чтобы привести структуру в соответствие с процессом разработки)

Автор: chaos 14.1.2010, 11:55

maxim1000, как все сложно блин  вообще в результате у меня должно получиться 2 приложения имеющие одно общее ядро ЗЫ не совсем понял как это уложить в то что описано выше :( ЗЫЫ релизится отдельн эти части не будут, только back-end + front-end1 = 1 исполняемый модул и back-end + front-end2 = 1 исполняемый модул Добавлено через 3 минуты и 6 секунд мне почему-то больше нравится такая структура project name --trunk ----core --branches ----frontend1(тут лежит полная копия core + все что необходимо для fe1) ----frontend2(тут лежит полная копия core + все что необходимо для fe2)

Автор: maxim1000 14.1.2010, 18:27

Цитата(chaos @  14.1.2010,  11:55 ) мне почему-то больше нравится такая структура project name --trunk ----core --branches ----frontend1(тут лежит полная копия core + все что необходимо для fe1) ----frontend2(тут лежит полная копия core + все что необходимо для fe2) здесь, ИМХО, получилась небольшая путаница: ветки - элемент процесса разработки, а не структуры кода например, когда мы собрались делать релиз, обычно создаётся стабилизационная ветка, в которой только баги чиним, а в основной - продолжаем разработку, кроме того, иногда используются ветки для разработки конкретных фич/прототипирования, чтобы своими экспериментами не мешать другим людям, сидящим на основной ветке в любом случае ветка содержит весь код продукта (по крайней мере, семантически) разные модификации - это уже, скорее, разные модули или даже разные продукты (см. вопрос ниже) Цитата(chaos @  14.1.2010,  11:55 ) ЗЫЫ релизится отдельн эти части не будут, только back-end + front-end1 = 1 исполняемый модул и back-end + front-end2 = 1 исполняемый модул т.е. два приложения (каждое из которых является back-end+front-end[i]) будут составлять единый пакет, который будет поставляться пользователю?

Автор: bilbobagginz 15.1.2010, 01:10

chaos,  принято в trunk засовывать либо корневой каталог основного проекта и доки, либо подпроекты и доки (но нередко доки есть для каждого под-проекта. в твоем бы случае рекоменовалось бы сделать так: Код trunk  - core  - fe1  - fe2  - doc branches  - exp1-with-fe2-test1  - - core  - - fe1  - - fe2  - - doc  - exp2-with-fe1-test3  - - core  - - fe1  - - fe2  - - doc  - fe1-test3-crazystuff tags  - release 0.2  - release 0.3  - release 0.5  - submission 0.7  - demo-competitors идея такая:  branches - это экспериментальные штуки, над которыми можно издеваться. можно напр. чтобы каждый разработчик имел свою ветку, для извратов. в своей ветке теоритически разработчик может напр. скоммитить некомпилируемый код, недоделанный набросок до отпуска. trunk - это как бы общак, в который коммитится организованный код, и прошедший regression tests. tags - это каталог особенных отметок символьными названиями - релизов, демок и т.д. с т.з. контроля доступа в каталог trunk можно сделать так, чтобы только тимлиды могли коммитить, но посмотреть могли бы все кодеры. в ветках - у каждого может быть ветка, в которой только он имеет доступ и чтения и писания. в тэгах можно создать каталог, доступный напр. клиенту, который скачивает проект. напр. в ветках можно сделать какой-то дополнительный фронтенд, пока его не  решили ввести в общак. надеюсь подход становится более понятным.

Автор: chaos 20.1.2010, 08:51

Цитата(maxim1000 @  14.1.2010,  15:27 ) т.е. два приложения (каждое из которых является back-end+front-end[i]) будут составлять единый пакет, который будет поставляться пользователю? именно так maxim1000, bilbobagginz спасибо за помощь !  Вчера не мог уснуть и переваривал написанное Вами. В итоге до меня все дошло: --repository name ----trunk ------my_mvc_fw_for_qt --------trunk --------branches --------tags ------app_core --------trunk --------branches --------tags ------app_view_qt --------trunk --------branches --------tags ------app_view_qml --------trunk --------branches --------tags ХМ только что заметил что у меня не так как в последнем посте Добавлено через 1 минуту и 52 секунды ЗЫЫ какие трудности меня ждут со структурой "описанной" мной?

Автор: maxim1000 20.1.2010, 09:20

а зачем верхний trunk? учитывая, что всё это будет единым пакетом, то есть предпосылки к выбору первой структуры (там, где все проекты вместе), иначе, когда начнутся ветки и релизы, эта структура может вызывать некоторые неудобства например, чтобы сделать стабилизационную ветку, придётся ветвить все проекты и внутри них переправлять ссылки, а в случае с альтернативной это можно сделать одним копированием

Автор: chaos 20.1.2010, 12:00

Цитата(maxim1000 @ 20.1.2010,  06:20) а зачем верхний trunk? те так? --repository name ----my_mvc_fw_for_qt ------trunk ------branches ------tags ----app_core ------trunk ------branches ------tags ----app_view_qt ------trunk ------branches ------tags ----app_view_qml ------trunk ------branches ------tags

Автор: maxim1000 20.1.2010, 12:30

Цитата(chaos @  20.1.2010,  12:00 ) те так? можно и так но если верхний trunk был зачем-то задуман, то лучше убирать его только если причина его существования пропала, не просто из-за вопроса "зачем?"

Автор: chaos 20.1.2010, 13:07

Цитата(maxim1000 @  20.1.2010,  09:30 ) но если верхний trunk был зачем-то задуман, то лучше убирать его только если причина его существования пропала, не просто из-за вопроса "зачем?"  щас пытаюсь про анализировать все + и - того и другого случая

Автор: powerOn 21.1.2010, 20:44

Цитата(maxim1000 @  20.1.2010,  09:20 ) а зачем верхний trunk? на одном уровне с trunk у тебя может существовать папка branches куда можно будет ветки складывать.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)