Итак, есть ядро проекта, от него идет три бранча, которые отличаются тем, что может быть изменена часть ядра и/или добавлен дополнительный код. В svn делается три бранча, но напрягает то, что при изменении ядра проекта изменения надо мержить в каждый из бранчей. А хотелось бы, чтоб они ядро как-то разделяли, не создавая подобного напряга. Поэтому буду благодарен тому, кто посоветует как это лучше сделать на svn, или любой другой системе контроля версий.

Здравствуйте, akorz, Вы писали:

A>Итак, есть

Это нужно архитектуру компонентную делать , а не SVNом решать.

И вопрос к управлению проектами не относится, это либо в архитектуру либо в средства разрботки.

Здравствуйте, Макс007, Вы писали:

М>Это нужно архитектуру компонентную делать , а не SVNом решать.

архитектуру никто менять не будет

М>И вопрос к управлению проектами не относится, это либо в архитектуру либо в средства разрботки.

может модераторы перенесут тогда, если ошибся разделом?

Здравствуйте, akorz, Вы писали:

A>Итак, есть ядро проекта, от него идет три бранча, которые отличаются тем, что может быть изменена часть ядра и/или добавлен дополнительный код. В svn делается три бранча, но напрягает то, что при изменении ядра проекта изменения надо мержить в каждый из бранчей. А хотелось бы, чтоб они ядро как-то разделяли, не создавая подобного напряга. Поэтому буду благодарен тому, кто посоветует как это лучше сделать на svn, или любой другой системе контроля версий.

Как я понимаю, автоматика здесь будет вредна.
Поскольку проект составляет единое целое. Особенности ядра как-то учитываются надстройками, и всё вместе сосуществует и отлаживается.
А тут — раз, накатил новое ядро. И всё заверте!

Так что осмысленное вливание ветки исправлений ядра в каждую ветку проекта — это правильный подход.

Возможно, что есть смысл завести trunk ядра отдельно от всего остального проекта?

Здравствуйте, akorz, Вы писали:

A>Здравствуйте, Макс007, Вы писали:

М>>Это нужно архитектуру компонентную делать , а не SVNом решать.

A>архитектуру никто менять не будет

Если с SVN то хотя бы изменить архитектуру репозиториев самый простой на мой взгляд это если ядро находится в отдельном репозитории,
например

./Kernel
./Brunch1

Тогда в Brunch1 нужно будет сделать svn:externals на kernel в репозитории и соотвественно .Kernel будет у всех общий из одного репозитория и коммит в каталоге .Kernel будет попадать всем.



A>может модераторы перенесут тогда, если ошибся разделом?

Это не известно. 50%х50% либо перенесут либо не перенесут.

Здравствуйте, Макс007, Вы писали:

М>./Kernel
М>./Brunch1

М>Тогда в Brunch1 нужно будет сделать svn:externals на kernel в репозитории и соотвественно .Kernel будет у всех общий из одного репозитория и коммит в каталоге .Kernel будет попадать всем.

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

Здравствуйте, Кодт, Вы писали:

К>Так что осмысленное вливание ветки исправлений ядра в каждую ветку проекта — это правильный подход.

правильный то, правильный, но столько геморроя казалось бы на ровном месте появляется. Вот хотелось бы избежать его
Мне тут один человек сказал, что возможно csv будем спасением, так как там версионность поддерживается для каждого файла отдельно, а не как svn на уровное ревизий. Я, правда с csv не работал так плотно, да и система вроде как устаревшая.

К>Возможно, что есть смысл завести trunk ядра отдельно от всего остального проекта?

есть такое, там ядро с общими модулями лежит.

Здравствуйте, akorz, Вы писали:

A>Итак, есть ядро проекта, от него идет три бранча, которые отличаются тем, что может быть изменена часть ядра и/или добавлен дополнительный код. В svn делается три бранча, но напрягает то, что при изменении ядра проекта изменения надо мержить в каждый из бранчей. А хотелось бы, чтоб они ядро как-то разделяли, не создавая подобного напряга. Поэтому буду благодарен тому, кто посоветует как это лучше сделать на svn, или любой другой системе контроля версий.
svn:external
и -1 за то, что не читаете документацию.

Здравствуйте, akorz, Вы писали:

A>Мне тут один человек сказал, что возможно csv будем спасением, так как там версионность поддерживается для каждого файла отдельно, а не как svn на уровное ревизий. Я, правда с csv не работал так плотно, да и система вроде как устаревшая.

Только не CSV (comma-separated values), а CVS (concurrent versions system).

Здравствуйте, akorz, Вы писали:

A>Здравствуйте, Макс007, Вы писали:
A>Ага, думал об этом, только вот ядро построено так, что в отдельную папку его никак не положить

Расстрелять архитектора и переписать или отрефакторить до компонента отдельного. Иначе поддержка выльется в большие бабки.