Уважаемый, ALL.

В качестве сиcтемы контроля версий используем CVS.
Возникла проблема при ведении параллельно нескольких проектов.

Существует основной проект и два проекта отпочковавшихся от основного. (Web-консоли на JSP и Struts)
Отличия между проектами небольшие, основная функциональность находится в корневом проекте.
Если вести проекты в разных бренчах — возникает ситуация когда при изменении общей для всех проектов части
регулярно приходится производить слияние между ветками. Это достаточно неудобно, потому что:
1. надо помнить о том какие изменения между ветками надо сливать , а какие не надо
2. количество отличающихся файлов достаточно большое и каждое слияни может потенциально привести к ошибке

Как порекомендуете выйти из данной ситуации.

З.Ы.
пока удобно работать в следующем формате
каждый проект — набор файлов хранящихся в разных бренчах. следовательно при изменении общей части, она автоматом изменится во всех подпроектах.
Единственный вопрос — как хранить такую структуру проекта (в тэгах не очень удобно, после внесения изменений в проект тег надо сохранять заново)

З.З.Ы
Может в SVN данная проблема решена?

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

Полагаю что данная проблема не решается с помощью инструментов контроля версий — это не их задача.
Имеет смысл структуру представить в виде независимых модулей (выделить независимые части и поместить их в отдельные проекты),
которые вы сможете выбирать Ant-ом во время построения кода вашего специфичного проекта.
Вообщем тут имеет смысл разобраться с архитектурами ваших проектов

С уважением,
Сергей.

PDV>Уважаемый, ALL.

PDV>В качестве сиcтемы контроля версий используем CVS.
PDV>Возникла проблема при ведении параллельно нескольких проектов.

PDV>Существует основной проект и два проекта отпочковавшихся от основного. (Web-консоли на JSP и Struts)
PDV>Отличия между проектами небольшие, основная функциональность находится в корневом проекте.
PDV>Если вести проекты в разных бренчах — возникает ситуация когда при изменении общей для всех проектов части
PDV>регулярно приходится производить слияние между ветками. Это достаточно неудобно, потому что:
PDV> 1. надо помнить о том какие изменения между ветками надо сливать , а какие не надо
PDV> 2. количество отличающихся файлов достаточно большое и каждое слияни может потенциально привести к ошибке

PDV>Как порекомендуете выйти из данной ситуации.

PDV>З.Ы.
PDV> пока удобно работать в следующем формате
PDV> каждый проект — набор файлов хранящихся в разных бренчах. следовательно при изменении общей части, она автоматом изменится во всех подпроектах.
PDV> Единственный вопрос — как хранить такую структуру проекта (в тэгах не очень удобно, после внесения изменений в проект тег надо сохранять заново)

PDV> З.З.Ы
PDV> Может в SVN данная проблема решена?

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

PDV>Уважаемый, ALL.

PDV>В качестве сиcтемы контроля версий используем CVS.
PDV>Возникла проблема при ведении параллельно нескольких проектов.

PDV>Существует основной проект и два проекта отпочковавшихся от основного. (Web-консоли на JSP и Struts)
PDV>Отличия между проектами небольшие, основная функциональность находится в корневом проекте.
PDV>Если вести проекты в разных бренчах — возникает ситуация когда при изменении общей для всех проектов части
PDV>регулярно приходится производить слияние между ветками. Это достаточно неудобно, потому что:
PDV> 1. надо помнить о том какие изменения между ветками надо сливать , а какие не надо
PDV> 2. количество отличающихся файлов достаточно большое и каждое слияни может потенциально привести к ошибке

PDV>Как порекомендуете выйти из данной ситуации.

Я думаю, что для CVS имеет смысл организовать стуктуру так:
common — директория общая для всех проектов
project1 — директория специфичная для проекта 1
project2 — директория специфичная для проекта 2

Изменения вести в бренчах не зависимых друг от друга, делать это удобней если держать вышеуказанные директории
в одном модуле. Например:
бренч FEATURE1 для common, project1
бренч INTEGRATION_WITH_NEW_LIB для common, project 2

Когда изменения специфичные для проекта протестированы, производить
merge в HEAD. Т.о. common/HEAD будет содержать оттестированные компоненты и не надо думать над тем
какие именно файлы сливать, а какие нет. Если невозможно перейти на другую систему контоля версий, то
возможно использовать CVSNT. Она backward compatible с CVS и перейти на нее можно очень быстро. Одним из ее
преимуществ над CVS в том, что мержить гораздо проще с MergePoint
В противном случае лучше перейти на другой SCM tool, но это сильно зависит от того что ваша организация
хочет от него получить.

Oops, предыдущее сообщение от меня.

Спасибо за ответ.
Но возникает следующая проблема. — перекрытие файлов.
Имеется ввиду, что в общей части и проекте порожденном от общего может присутствовать файл с одним и тем же именем
Следовательно в Ant-е для каждого подпроекта должны быть прописаны какие файлы и откуда брать. и этот список необходимо постоянно контролировать.

Например.
в общем проекте есть login.jsp
в подпроект №1 нет своего login.jsp , используется из основного проекта
в подпроекте №2 есть login.jsp (отличается от используемого в основном проекта) €

Спасибо за ответ.
Но возникает следующая проблема. — перекрытие файлов.

Например.
в общем проекте есть login.jsp
в подпроект №1 нет своего login.jsp , используется из основного проекта
в подпроекте №2 есть login.jsp (отличается от используемого в основном проекта)

т.е не получается четко определить, что будет common, а что custom.

а какие SCM tools позволяют разрешить данную задачу на ваш взгляд?

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

PDV>в общем проекте есть login.jsp
PDV>в подпроект №1 нет своего login.jsp , используется из основного проекта
PDV>в подпроекте №2 есть login.jsp (отличается от используемого в основном проекта)

PDV>т.е не получается четко определить, что будет common, а что custom.

PDV>а какие SCM tools позволяют разрешить данную задачу на ваш взгляд?
По-моему, это должно определяться на уровне структуры проекта, build-файлов. Нечего тут делать с системами контроля версий.
По идее, обычное разбиение на фолдеры и относительные пути, прописывание CLASSPATH или include-paths решает эту задачу.
В svn есть svn:external, но это несколько другое. Например, если несколько программ используют некую библиотеку, скажем, libxml2, то её можно заставить checkout-итиься из некоего одного места (даже прямо с gnome svn-сервера) в каталоги каждого проекта.

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

PDV>Спасибо за ответ.
PDV>Но возникает следующая проблема. — перекрытие файлов.
PDV>Имеется ввиду, что в общей части и проекте порожденном от общего может присутствовать файл с одним и тем же именем
PDV>Следовательно в Ant-е для каждого подпроекта должны быть прописаны какие файлы и откуда брать. и этот список необходимо постоянно контролировать.

Никто не говорил что будет легко
Вообще если серьезно — веб проекты работа довольно штучная и добиться в них определенного уровня обовщенности трудно.

PDV>Например.
PDV> в общем проекте есть login.jsp
PDV> в подпроект №1 нет своего login.jsp , используется из основного проекта
PDV> в подпроекте №2 есть login.jsp (отличается от используемого в основном проекта) €

Мое мнение — login.jsp есть сущность вполне определенная и выполняющая конкретную задачу.
Непонятно чем оно может отличаться кроме "шкурок" выполненных например на основе XML/XSL (а эти вещи вы можете брать по метке, напрмер в
папочке /skins@@VERSION_1 или /skins@@VERSION_2 для конкретного проекта).
В любом случае в системе контроля версий готового решения нет — вам надо набросать план самому или дать это задание вашему CM инженеру.

Краткое послесловие Вдруг кому пригодится.
В итоге используем Ant-ие скрипты для сборки проекта из нескольких ветвей лежащих в CVS-репозитории.
Достаточно удобно оказалось.