Source Control - Проекты с открытым исходным кодом

Question

Я столкнулся с общей дилеммой.

Часто наша компания полагается на использование библиотек с открытым исходным кодом для достижения цели, но иногда нам приходится изменять их, чтобы они могли работать на разных платформах, исправлять ошибки и т. Д.

Мы используем комбинацию subversion: TortoiseSVN и AnkhSVN.

Есть ли способ для следующего сценария работать с SVN:

• Devs добавляет исходный код из проекта с открытым исходным кодом в нашу Subversion (обычно через экспорт, в зависимости от того, какой элемент управления исходным кодом они используют)
• Разработчики вносят несколько изменений в открытый исходный код
• Создатель проекта с открытым исходным кодом делает несколько собственных улучшений и исправлений ошибок
• Как объединить изменения из проекта с открытым исходным кодом в нашу Subversion?

Если SVN не может сделать это, есть ли лучший вариант контроля версий для нас? Мы бы предпочли один с интеграцией Visual Studio, если это возможно.

Answer 1

Subversion может сделать это, конечно. Подобные вещи происходили до того, как существовали распределенные VCS. См. Раздел Ветви поставщика из Глава 4. Ветвление и слияние в книге Subversion.

Цитата:

Управление ветвями поставщиков обычно работает следующим образом: сначала вы создаете каталог верхнего уровня (например, / vendor) для хранения ветвей поставщиков. Затем вы импортируете сторонний код в подкаталог этого каталога верхнего уровня. Затем вы копируете этот подкаталог в свою основную ветку разработки (например, / trunk) в соответствующем месте. Вы всегда вносите свои локальные изменения в основную ветку разработки. С каждым новым выпуском кода, который вы отслеживаете, вы переносите его в ветку поставщика и объединяете изменения в / trunk, разрешая любые конфликты, возникающие между локальными изменениями и исходными изменениями.

Answer 2

Subversion здесь не тот инструмент. Для того, что вы ищете, требуется распределенная система управления версиями, что в основном означает, что вы можете перемещаться по репозиториям и не иметь центрального репозитория.

Проверьте Git и Mercurial для получения дополнительной информации. Если вышестоящий проект использует Subversion, вы можете использовать git-svn в качестве моста - вы создаете свой собственный репозиторий, меняете вещи, и вы все равно можете объединить svn в него, а также отправить в свой собственный «upstream / central» git-репозиторий.

Также обратите внимание: есть ли причина, по которой вы не вносите свои изменения непосредственно в проект? (Особенно, если проект лицензируется под чем-то вроде GPL или LPGL, что вынуждает вас публиковать ваш измененный исходный код для широкой публики под подходящей лицензией, которой являются многие проекты). Кажется, это был бы отличный способ вернуть людям, которые дают вам код бесплатно ...

Следующий вопрос адресован Git + Visual Studio: Использование Git с Visual Studio