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

Question

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

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

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

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

Answer 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 на единицу меньше набора изменений, который вы хотите остановить на

Answer 2

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

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

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

http://svnbook.red -bean.com / ен / 1.5 / СВН-book.html # svn.branchmerge.basicmerging.undo

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

Answer 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), я при необходимости возвращаю ее обратно в ветку текущего выпуска (например, branch / R1).

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