Доброго времени суток!
Прошу прощения если не туда запостил, мне показалось туда 

К делу!
Начинается новый проект. Проект не очень то и большой(~200 классов).
Столкнулся с проблемой: как все это дело хранить в системе контроля версия(был выбран SVN)

Краткое описание проекта:

есть ядро(бэкенд и тп). будет 2 фронт енда.
для одного фронтенда ядро будет браться в том виде в котором есть, а для второго существующее ядро как бы обернется в понятия чуть-чуть более высокого уровня, но без изменения самого ядра.

с SVN не сильно дружу, тк в работал только с trank версиями проектов. по этому про ветки и тп мало чего знаю.


Подскажите как мне правильно организовать хранилище?


ЗЫ я себе картину представляю следующим образом: напишится ядро. создадутся две ветки frontend1 & frontend2 и там будет вестись вся работа.

чаще всего используется одна из двух структур:

1.
root
--trunk
----project1
----project2
--branches
----branch1
------project1
------project2
...

2.
root
--project1
----trunk
----branches
------branch1
--project2
----trunk
----branches
------branches1

выбирается та, которая более соответствует связанности проектов
если у каждой из трёх частей будет свой цикл релизов, связность между ядром и фронт ендами небольшая, стоит выбрать вторую
если все три куска кода будут представлять собой единое целое и релизиться одним куском, есть смысл выбрать первую структуру

обнаружить неправильный выбор структуры очень просто - с ней будет неудобно работать
(правда, к сожалению, многие начинают терпеть "объективные трудности", героически с ними бороться, писать всякие скрипты и полноценные приложения для создания веток, вместо того, чтобы привести структуру в соответствие с процессом разработки)

Это сообщение отредактировал(а) maxim1000 - 14.1.2010, 11:40

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)


Это сообщение отредактировал(а) chaos - 14.1.2010, 11:56

здесь, ИМХО, получилась небольшая путаница: ветки - элемент процесса разработки, а не структуры кода

например, когда мы собрались делать релиз, обычно создаётся стабилизационная ветка, в которой только баги чиним, а в основной - продолжаем разработку, кроме того, иногда используются ветки для разработки конкретных фич/прототипирования, чтобы своими экспериментами не мешать другим людям, сидящим на основной ветке

в любом случае ветка содержит весь код продукта (по крайней мере, семантически)

разные модификации - это уже, скорее, разные модули или даже разные продукты (см. вопрос ниже)


т.е. два приложения (каждое из которых является back-end+front-end[i]) будут составлять единый пакет, который будет поставляться пользователю?

chaos, 

принято в trunk засовывать либо корневой каталог основного проекта и доки, либо подпроекты и доки (но нередко доки есть для каждого под-проекта.
в твоем бы случае рекоменовалось бы сделать так:

идея такая: 
branches - это экспериментальные штуки, над которыми можно издеваться. можно напр. чтобы каждый разработчик имел свою ветку, для извратов. в своей ветке теоритически разработчик может напр. скоммитить некомпилируемый код, недоделанный набросок до отпуска.
trunk - это как бы общак, в который коммитится организованный код, и прошедший regression tests.
tags - это каталог особенных отметок символьными названиями - релизов, демок и т.д.
с т.з. контроля доступа в каталог trunk можно сделать так, чтобы только тимлиды могли коммитить, но посмотреть могли бы все кодеры.
в ветках - у каждого может быть ветка, в которой только он имеет доступ и чтения и писания.
в тэгах можно создать каталог, доступный напр. клиенту, который скачивает проект.

напр. в ветках можно сделать какой-то дополнительный фронтенд, пока его не  решили ввести в общак.

надеюсь подход становится более понятным.

именно так
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 секунды
ЗЫЫ какие трудности меня ждут со структурой "описанной" мной?

а зачем верхний trunk?

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

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

Это сообщение отредактировал(а) maxim1000 - 20.1.2010, 09:25

те так?

--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

можно и так
но если верхний trunk был зачем-то задуман, то лучше убирать его только если причина его существования пропала, не просто из-за вопроса "зачем?" 

щас пытаюсь про анализировать все + и - того и другого случая

на одном уровне с trunk у тебя может существовать папка branches куда можно будет ветки складывать.