общие файлы для разных проектов, синхронизация и контроль версий Опции

[ukpyr]

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

кто как решает ?

Сообщение отредактировал ukpyr - Sep 11 2009, 09:30

[ukpyr]

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

[dxp]

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

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

[des00]

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

как раз вопрос в тему. про svn_externals выглядит это все красиво, но вот сейчас столкнулся вот с чем (работаю с ФПГА).

Есть у меня проект под названием "общие компоненты". Пока компоненты в нем были маленькие (занимали один файл) все было хорошо. Использовал я этот проект в N ом количестве других проектов, при этом ссылался на него как svn::external ../common_comp/trunk/rtl. Компоненты под проект не кастомизировались, но если в них находилась ошибка, то она исправлялась по месту + делался коммит в корневое дерево проекта общих компонентов.

Теперь нарисовался у меня компонент файлов на 10. из них в релиз идет только 7 файлов, т.к. остальные файлы рабочие, используемые при отладке. Также при разработке этого компонента был создан мини проект и его структуру хотелось бы сохранить для возможного устранения ошибок в будущем. Но в описанную выше технику использования либы этот многофайловый компонент, часть файлов которого не нужна, не вписывается. Действительно зачем при использовании компонента мной или кем то другим видеть файлы, которые для этого не нужны.

собственно вопрос, как грамотно обрулить данную ситуацию?

Я вижу пока только вариант сбора всех проектов общих компонентов в trunk в одной папке и релизы этих компонентов в tag. Правда в этом случае правка багов должна идти сложнее : правим в папке проекта общих компонентов, затем делаем очередной релиз, затем переписываем svn_externals. Но это как то коряво.

Может как то можно сделать псевдоним в SVN. Например я веду релизы и по псевдониму например CURRENT_RELEASE SVN вытаскивет нужный мне релиз и не потребуется ручками править svn_externals?

[Legotron]

собственно вопрос, как грамотно обрулить данную ситуацию?

не претендую на грамотность
А может воспользоваться POST-COMMIT HOOK. Написать скрипт, который после коммита проекта с либой создаст tag, содержащий нужные файлы, который всегда будет связан svn:externals с проектом, в котром используется эта либа.
Таким образом вы правите тестовый проект, производите фиксацию, нужные файлы попадают в tag, который связан svn:externals с другим проектом.

P.S. Не бейте сильно, если чушь написал. я из благих намерений