4

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

Я сомневаюсь, что с этим можно легко справиться, не сталкиваясь с конфликтами вручную, поэтому позвольте мне задать альтернативный вопрос: если я создал репозиторий с некой общей библиотекой кода, а затем внес в проект какие-либо конкретные изменения отдельные файлы, использующие наследование классов, возможно ли настроить его так, чтобы в одной папке были извлечены два хранилища?

4 ответа4

4

Это трудно сделать в SVN. Это требует много ручного слияния и подвержено ошибкам. Однако, если у вас есть опция, как упоминает @Ash, распределенные системы контроля версий справляются с этим сценарием достаточно хорошо. В частности, я знаю, что Git делает это чрезвычайно легко.

Команда git-rebase делает именно то, что вы хотите. Предполагая, что у вас есть основная ветка или "источник" вашего источника, вы просто создаете новую ветвь ("mywork"), чтобы внести изменения в свой проект (представлены блоком C6).

Филиал проекта

Теперь, когда основная ветвь кода продолжает изменяться (ревизия C3 и C4), вы просто переводите ветку, специфичную для вашего проекта, на новую ревизию, и вы получите все изменения, которые были сделаны в основной ветке в ветке вашего проекта. ,

Перебазировать граф

Все еще есть возможность слияния вручную, но вероятность сделать это гораздо ниже. Git снимает много боли с выполнения операции слияния. Проверьте главу Git Book о перебазировании для получения дополнительной информации.

1

Я думаю, что это довольно сложно сделать с Subversion (по крайней мере, с текущими версиями), если не невозможно, но распределенная система контроля версий с этим справится. Я использовал Mercurial для решения этой проблемы:

На стороне сервера:

  • Создать "главный" репозиторий
  • Клонируйте этот репозиторий, чтобы сделать специфическую для проекта версию репозитория (клонирование - это создание копии всего репозитория где-то еще)

На стороне клиента:

  • Клонируйте репозиторий проекта в свою область разработки и проверьте его
  • Внесите изменения, много сделайте локально и, при необходимости, отправьте обратно на сервер

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

Вероятно, есть большая кривая обучения при выполнении всего этого, но, возможно, стоит исследовать.

1

Короткий ответ - нет". Проблема, которую вы описываете, заключается в объединении ветвей, когда происходят изменения. Существуют инструменты, которые помогут, но в итоге вы объединяете две ветви кода, которые обе изменились. Эта ситуация может вызвать конфликт, который потребует вмешательства человека.

0

Разве этот вопрос не намного лучше задан на SO (который имеет более 5000 вопросов SVN)? Я вижу, что здесь есть несколько вопросов по SVN, но я не знаю, что делает их более подходящими для любого сайта.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .