Как удостовериться, что исправления ошибок в ответвлении версии в Подверсии объединяются в соединительную линию

Начиная с версии 1.5, SVN помещает информацию об объединенных ревизиях в свойства. Вы должны найти это там и разобраться в этом. Однако это только говорит вам, какие ревизии были объединены, но не какие ревизии забыли объединить.

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

There's nothing in SVN to tell you what code you should or should not checkin, branch, merge or delete. That's not its job. It does its job perfectly well - which is providing you with a versioned tool to store your code in.

So, you don't need a tool to manage your code better, you need an external system to manage your developers better :)

One way is QA, test and a bug tracker - as code changes are made, the fact that something was done to the code is recorded and tracked through the various phases. You typically do not want anyone making changes to code without some reason (other than 'I felt it needed refactoring') so a tracking tool is a good idea anyway. As bugs are fixed in one release, this tool can be used to ensure that the bug is fixed in other ones too (when appropriate - sometimes you don't want a particular change made to a release)

SVN can integrate with these tools, for example, my repo updates my Mantis bugtracker when some magic words are added to a checkin (if you type "fixed mantis #1234" in the checkin comment, mantis bug 1234 will be updated with the changed files and its status changed to 'waiting test')

Alternatively tools such as reviewboard can integrate too - as you make a change, the revision can be posted there for others to sign off, sign off process can include ensuring the bug is merged, or a new bug report is created for the other releases you require it fixing in too.

So - the problem is not with SVN here, its with your development processes.

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

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

В более новых версиях Subversion (я думаю, начиная с 1.5 или 1.6) есть отслеживание слияния. То есть Subversion отслеживает, какие из изменений в ветке были объединены с транком.

Вы можете объединить все изменения из ветки в ствол, используя команду:

svn co https://server/repo/trunk
cd trunk
svn merge --reintegrate https://server/repo/branches/branch_name
<check merge results, run unit tests, etc>
svn commit

Подробнее см. Руководство по Subversion подробности.

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

You might want to adapt the strategy Subversion developers use themselves: do most of the development in trunk, release from branches. When a bug is found it's first fixed in trunk and then the fix is merged from trunk to the branch.

Вот что мы делаем, я только что писал об этом - мы устанавливаем специальную сборку на нашем сервере CI, которая каждую ночь проверяет, что нет не объединенные изменения существуют.

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

Вы можете найти сценарий по адресу: http://github.com/ccampbell/show-missing-revs

Допустим, у вас есть ветка выпуска 2.0. Чтобы узнать все, что было зафиксировано в 2.0, что еще не было объединено с основной линией:

cd /path/to/trunk
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose)

Это даст что-то вроде:

r2532 | username | fixing bug with this
r2631 | username | fixing bug with that

Мне кажется, для этого требуется subversion 1.5. Надеюсь, вы найдете это полезным!