LINUX.ORG.RU

[svn] Организация двух проектов, разделяющих общие файлы

 


0

0

Проблема такая: хочу перевести свой проект под управление svn, но не могу понять, как организовать хранилище.

Сейчас ситуация такая: проект имеет несколько библиотек функций. Для каждой библиотеки написан отдельный тест-кейз, который проверяет корректность работы этой библиотеки. Тест-кейз сам по себе является проектом -- у него есть свой make-файл и ряд вспомогательных файлов. Естественно, если библиотека вдруг работает неправильно, в ее код вносятся изменения. Сейчас это сделано с помощью символической ссылки -- на самом деле есть один файл библиотеки, который можно изменять как в основном проекте, так и в тест-кейзе. В чем проблема с такой организацией? А в том, что если немного поменять формат библиотеки в основном проекте, то при тестировании приходится "подгонять" тест-кейз к новому формату и много времени уходит, чтобы понять, что и как изменить, чтобы тест-кейз просто заработал. Образно можно себе представить это так: есть два разработчика -- один пишет основной проект, один -- тест-кейз, оба в процессе работы изменяют общий файл -- текст библиотеки, всё остальное у них разное, есть даже файлы с одинаковыми именами, но разным содержимым (Makefile'ы, например), т.е это ситуация двух проектов с одним общим файлом, в котором необходимо разруливать конфликты изменений.

Чего хочется: хочется всю эту систему отдать под управление svn так, чтобы все изменения, сделанные в библиотеке были видны и в тест-кейзе и наоборот, исправления, внесенные при отладке были видны в основном проекте. Если рассматривать проблему предыдущего параграфа, то хотелось бы, чтобы система версий составляла саммари всех изменений в коде библиотеки, которые "видны" из обоих проектов и позволяют облегчить работу по "подгонке" остального кода. Ну и, конечно, хочется поиметь и все "плюшки" от работы с VCS -- протоколирование изменений, версионирование и т.д. и т.п.

Вопрос: как это сделать, минимально ломая структуру обоих проектов? И вообще, с минимумом усилий? Все, что пока пришло мне в голову -- сделать тест-кейз веткой основного проекта, удалить все файлы, кроме исходника библиотеки, добавить туда "свои" файлы и с этим работать, но это... топорно как-то.

svn:externals, насколько я понимаю.

Хотя лучше бы воспользоваться случаем и обдумать структуру проектов :)

tailgunner ★★★★★
()
Ответ на: комментарий от annoynimous

> Я уже мозг сломал, обдумывая :)

Ну то есть идея сделать тесткейс частью библиотеки рассмотрена и отвергнута?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ну то есть идея сделать тесткейс частью библиотеки рассмотрена и отвергнута?

Видишь ли, а если это не простой тесткейс, а вполне полноценный подпроект?

Ну смотри, давай рассмотрим абстрактный случай: есть проекты A и B, оба используют библиотеку L. Библиотека L находится в разработке. Скажи, здорово ведь бы было, если оба проекта A и B могли бы видеть изменения, которые внесены в код библиотеки, по сравнению с их локальными копиями?

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

> давай рассмотрим абстрактный случай: есть проекты A и B, оба используют библиотеку L. Библиотека L находится в разработке. Скажи, здорово ведь бы было, если оба проекта A и B могли бы видеть изменения, которые внесены в код библиотеки, по сравнению с их локальными копиями?

svn:externals, http://svnbook.red-bean.com/en/1.1/ch07s04.html

Но, скорее, видимы должны быть не любые изменения, а "релизы". Такая техника называется "vendor branches": http://svnbook.red-bean.com/en/1.1/ch07s05.html

P.S. Я уже говорил, что SVN - устаревшее говно? :) Хотя в новых системах вроде Mercurial этим вопросам уделено еще меньше внимания :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Да понимаешь, мне в общем-то все равно, что использовать -- я только учусь, осваиваюсь с новыми терминами, парадигмами и приемами работы. Так что на этой стадии я выбрал то, что мне показалось более легким для освоения. С другой стороны, меня интересуют именно централизованные VCS, а не распределенные, поскольку я пока единственный разработчик (правда ведущий несколько родственных проектов параллельно).

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Но за рекомендации спасибо, конечно!

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

> С другой стороны, меня интересуют именно централизованные VCS, а не распределенные, поскольку я пока единственный разработчик

Не влияет. Я довольно долго использовал Mercurial для исключительно сольной работы :) Вообще, mq рулит и педалит вне зависимости от распределенности.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.