Subversion филиал реинтеграции
Я хотел немного уточнить ответ безжизненным , потому что, когда я начал читать о том, как использовать super () в иерархии множественного наследования в Python, я не получил его немедленно.
Что вам нужно понять, так это то, что super(MyClass, self).__init__() предоставляет следующий метод next __init__ в соответствии с используемым алгоритмом упорядочивания разрешения метода (MRO) в контексте полного наследования иерархия .
Эта последняя часть имеет решающее значение для понимания. Рассмотрим снова пример:
class First(object):
def __init__(self):
super(First, self).__init__()
print "first"
class Second(object):
def __init__(self):
super(Second, self).__init__()
print "second"
class Third(First, Second):
def __init__(self):
super(Third, self).__init__()
print "that's it"
В соответствии с этой статьей о порядке разрешения метода Гвидо ван Россума вычисляется порядок разрешения __init__ (до Python 2.3) используя «перекос по левому краю по глубине»:
Third --> First --> object --> Second --> object
После удаления всех дубликатов, кроме последнего, получаем:
Third --> First --> Second --> object
Итак, позволяет следить за тем, что происходит, когда мы создаем экземпляр класса Third, например x = Third().
- В соответствии с MRO
__init__третьего вызывается первым. - Далее, согласно MRO, внутри метода
__init__super(Third, self).__init__()разрешается__init__метод First, который вызывается. - Внутри
__init__Первогоsuper(First, self).__init__()вызывает__init__из Во-вторых, потому что это то, что диктует MRO! - Внутри
__init__of Secondsuper(Second, self).__init__()вызывает__init__объекта, что ничего не значит. После этого будет напечатан «второй». - После завершения
super(First, self).__init__()будет напечатан «первый». - После завершения
super(Third, self).__init__()будет напечатан «это все».
Это объясняет, почему создание экземпляра Third () приводит к:
>>> x = Third()
second
first
that's it
. Алгоритм MRO был улучшен с Python 2.3, чтобы хорошо работать в сложных случаях, но я думаю что использование «перемотки по глубине слева направо» + «удаление дубликатов ожидается для последнего» все еще работает в большинстве случаев (прокомментируйте, если это не так). Обязательно прочитайте сообщение в блоге Guido!
9 ответов
Можно сделать это технически, Вы переходите, не мертво, ни отключен, но не рекомендуется объединиться от ответвления для транкинга после реинтеграции.
можно найти полную дискуссию о причине этого, здесь: слияние Подверсии повторно интегрирует
В основном, оно говорит, что возможно объединить Ваши изменения снова в соединительной линии, но так как реинтеграция вынуждает Вас объединиться от соединительной линии для ветвления до повторно интегрировать операции, Вы будете сталкиваться с Отражающим/Циклическим Слиянием, которое очень проблематично в Подверсии 1.5.
В соответствии со статьей, рекомендуется сразу удалить Ваше повторно интегрируемое ответвление после реинтеграции и создать новую с тем же (или отличающийся) имя вместо этого.
Это - известное поведение Подверсии, которое будет обращено в будущей версии (вероятно, в 1,6)
<час>Поскольку все уже сказали это здесь: ответвление не мертво и соглашается на ответвление, может продолжиться очень хорошо.
Иногда, хотя Вы хотите уничтожить ответвление после слияния. Единственное надежно решение должно удалить ответвление. Оборотная сторона - то, что затем более трудно найти ответвление снова, если Вы хотели взглянуть на него, скажем, по историческим причинам. Так, многие люди разбрасывают "важную" ложь ответвлений и наличие соглашения о не изменении их. Мне жаль, что не было способа отметить мертвое/только для чтения ответвление, таким образом гарантируя, что никто не может согласиться на него до следующего приказа.
Можно продолжить разрабатывать на ответвлении, функция, в которой Вы будете нуждаться, отслеживание слияния , который находится в Подверсии 1.5, это означает, что дополнительные слияния от ответвления только включают новые изменения.
Можно объединиться от ответвления, чтобы соединить магистралью, или соединить магистралью к ответвлению, так много раз, как Вы хотите.
Когда Вы делаете слияние, Вы указываете цель. Можно объединить различия TreeA и TreeB к TreeC, если Вам нравится. Поскольку Chris подразумевает, Ваш вопрос действительно не имеет так большого смысла. При слиянии ответвления в соединительную линию ответвление остается нетронутым. Если ответвление не необходимо впоследствии, Вы могли бы удалить его.
Нет, ответвление все еще живо, но в тот момент это - точно то же как соединительная линия. Если Вы продолжаете разрабатывать на ответвлении, Вы свободны повторно объединиться с соединительной линией позже.
Некоторый совет относительно слияния изменений назад, если кто-то вносит изменения в ответвление многократно (пред 1,5): Помнят, в котором пересмотре Вы сделали слияние ! Или запишите числа пересмотра где-нибудь, или (который легче) , делают тег . (Можно, конечно, узнать это позже, но это - ЛАВАШ.)
Пример:
у Вас есть расположение репозитория как это:
/your_project
/trunk
/branches
/tags
Скажем, это - веб-приложение, и Вы запланировали сделать выпуск. Вы создали бы тег, и от того (или от соединительной линии) ответвление, в котором Вы делаете bugfixes:
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
Выполнение его этот путь, можно интегрировать новые возможности в соединительной линии. Весь bugfixes произошел бы только в рамках ответвления bugfix и перед каждым выпуском, Вы делаете тег текущей версии (теперь от ответвления bugfix).
Позволяют нам предположить, что Вы сделали изрядное количество bugfixing и выпустили bugfixing к рабочему серверу, и Вам нужна одна из тех функций отчаянно в текущей соединительной линии:
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
можно теперь просто интегрировать изменения между 1.0.0 и 1.0.2 в соединительной линии (предполагающий, что Вы находитесь в своей рабочей копии):
svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .
Это - то, что необходимо помнить. Вы уже объединили изменения между 1.0.0 и 1.0.2 на соединительную линию. Давайте предположим, что в текущем производственном выпуске существует больше изменений:
/your_project
/trunk
/branches
/1.0.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
/1.0.3
/1.0.4
Вы теперь готовы выпустить новую версию от соединительной линии, но последние изменения Вашего bugfixes все еще отсутствуют:
svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .
Теперь Вы имеете весь изменения, объединенные на Вашей соединительной линии, и можно сделать выпуск (не забывайте тестировать его сначала).
/your_project
/trunk
/branches
/1.0.0-bugfixes
/1.1.0-bugfixes
/tags
/1.0.0
/1.0.1
/1.0.2
/1.0.3
/1.0.4
/1.1.0
После реинтеграции из ветки в ствол вы должны сделать одно из двух:
Удалить свою ветку. Это проще всего, но так будет сложнее просмотреть историю ветки.
Попросите свою ветку не сливать коммит reintegrate. Если вы реинтегрируетесь в ствол и зафиксируете его как ревизию X, вы можете выполнить эту команду в своём филиале:
svn merge --record-only -c X url-to-trunk. Однако не стоит этого делать, если вы внесли в коммит какие-либо изменения, кроме самого слияния. Любые другие изменения никогда не вернутся в вашу ветку.
На самом деле вам нужно выполнить слияние - только для записи из основной ветви в свою ветку ревизии, созданной - reintegrate commit:
$ cd trunk
$ svn merge --reintegrate ^my-branch
$ svn commit
Committed revision 555.
# This revision is ^^^^ important
И теперь вы записываете это
$ cd my-branch
$ svn merge --record-only -c 555 ^trunk
$ svn commit
Теперь вы счастливы сохранить ветку
Подробнее см. Глава 4. Ветвление и слияние, расширенное слияние .