Subversion - как переместить некоторые изменения из ствола в ветку?

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

Ситуация в основном:

/proj/trunk/A/
/proj/trunk/B/
/proj/trunk/C/

У нас есть ревизии a..z, зарегистрированные со времени последней версии. Изменения d, f, g и j..n содержат работу, связанную с новой функцией в C, которая не будет завершена вовремя. Изменения e, h и q содержат несвязанные изменения в C, которые должны быть в этом выпуске. Я хотел бы создать /proj/branches/new-feature-for-C/ и переместить изменения d, f, g и j..n там, сохраняя e, h и q в trunk. Между изменениями, которые нужно переместить в ветвь, не существует совпадений, и изменения, которые необходимо сохранить в соединительной линии, и никакие изменения, которые нужно переместить в ветвь, зависят от любых изменений в любом другом подпроекте с момента последней версии.

Ответ 1

Вот как я это сделаю: скопируйте ствол в ветку, а затем смените слияние наборов изменений.

поэтому, если ствол имеет значение http://svnserver/svn/myrepo/trunk/C и наборы нежелательных изменений: 3, 6 , 9-11

svn copy http://svnserver/svn/myrepo/trunk/C http://svnserver/svn/myrepo/branch/C -m "Branch no completable work"
svn merge -c -3,-6 http://svnserver/svn/myrepo/trunk/C <filepath to root of trunk>
svn merge -r 11:8 http://svnserver/svn/myrepo/trunk/C <filepath to root of trunk>
****CHECK EVERY THING WORKED***
svn commit . -m "Removed some changes that weren't to be finished"

Обратите внимание, что -r 11:8 на один меньше, чем набор изменений, который вы хотите остановить на

Ответ 2

Это не отвечает на ваш вопрос, но в будущем вы должны разработать каждый из ваших подпроектов в другой ветке для начала. Только когда подпроект завершен и готов к отправке, если он будет объединен в багажник. Таким образом, багажник всегда находится в состоянии shippable.

Единственная проблема заключается в том, что для двух разных подпроектов необходимо использовать один и тот же новый код. Subversion делает этот случай сложным, но другие системы контроля версий, такие как Git, Mercurial и Bazaar, делают этот случай легким.

Что касается ответа на ваш реальный вопрос, следующий URL-адрес объясняет, как отменить конкретный номер версии:

http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.basicmerging.undo

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

Ответ 3

Существует множество способов настройки репозиториев, но, как я обычно это делаю, это.

trunk - always tracks the latest code in development that will definitely get released
branches/R1 - when I do a release, I create a branch for it, and also a tag (see below R1.0). This branch always tracks the latest version of Release 1.x. If I need to go back, I use the tags, below.
branches/Import Tool - when I am working on a standalone feature that may not get released with latest code (e.g., main product is a calendar, import tool may not be ready in time).
tags/R1.0
tags/R1.1 - every time I release an update to a release, I create a tag, so that I can easily revert to that version e.g., if I need to reproduce a bug
tags/R1.2

Когда я нахожу ошибку в последнем коде (trunk), я объединю его обратно в текущую ветвь выпуска (например, ветки /R 1), если это необходимо.

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