Рекомендации по выбору иерархии проектов и структуры VCS
От: AlexNek  
Дата: 14.06.16 22:03
Оценка:
Имеется много различных проектов от больших до маленьких. Может быть одно ехе, а может быть в придачу и более десятка длл-ок (суб — проектов). Длл-ки могут быть специфичны для проекта, а могут быть и общие.
Имеется достаточное количество клиентов у которых может быть от одного до нескольких проектов, причем стандартный проект может быть допилен для требований именно этого клиента.
Время жизни проектов может быть и более 10 лет. Проекты часто "доделываются" у клиентов, ну типа записать данные на сервер клиента. Проекты завязаны с оборудованием, так что протестить всё на фирме может быть вообще невозможно.
Соотвественно нужно точно знать у кого какая версия установлена, так как иногда нужно или конкретную ошибку исправить или что добавить.
Варианты решения (только некоторые, неподходящие)
1. Заводим репозиторий на проект, куда скидываем весь код, с папочками по клиентам, где в папочке может быть "ветка" клиента.
Основной код отмечается меткой релиза для клиента.
Для SVN и проектов из одного ехе достаточно удобно.
Но как только появляются общие субпроекты приходится всё дублировать либо забирать данных из нескольких репозиториев.

2. Заводим общий репозиторий на все проекты и раскидываем всё на папочки как и в варианте 1.
Появляется возможность управления общими суб-проектами, которая однако "убивает" версии клиентов. Пример: в январе отдан проект П1, с субпроектами СП1 и СП2, в мае отдается проект П1, с измененными версиями СП1 и СП2, в сентябре требуются изменения для П1, а он уже не компилируется с изменеными версиями СП1 и СП2 или есть вероятность появления новых ошибок специфичных только для П1 в связи с изменениями СП1 и СП2.
Ну и для удаленного SVN доступа (интернет часто бывает доступен только через мобильный телефон) большой репозиторий просто не подъемен, даже если просто структуру смотреть. Хотя проблемы SVN можно решить GIT-ом (только вроде в студии 2013 какого то типа доступа не хватает к нему)
Ну и для общего репо неясно для каких именно субпроектов нужно делать метку/ветку для конкретного клиента/проекта.

Пока начальный путь видится в создании общего репозитория, с транками/метками/ветками на каждый проект и с транком/метками/ветками на общие субпроекты.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.