Преобразование проекта WordPress в процедуру ветки поставщика
Если вы используете svn в первый раз, я полагаю, вы не начали с чистой копии WordPress, разветвились оттуда и отредактировали разветвленную версию, не так ли? ;)
Если это так, у вас может быть проблема в ваших руках.
Фон
В отличие от "обычных различий", объединение SVN не сравнивает правый код / папки с левым кодом / папками.
Хотя svn merge может прибегнуть к diff-like механизму, если он не находит историю, я бы не рекомендовал полагаться на это, поскольку он может быть весьма подвержен ненужным конфликтам.
SVN Merge используется для воспроизведения изменений, которые были записаны в истории SVN. Это все равно, что сказать художнику: «Эй, ты знаешь, как выглядела эта картина, до того, как ты добавил это дерево на холм? Это дерево было великолепным! опять дерево, но на этой фотографии с закатом? "
Художник может воспроизвести дерево, потому что он знает, как он это сделал. У него даже может быть где-то черновик.
Картинка, это WordPress. Художник, его свн с тобой командует. Дерево вот твои модификации. Картинка теперь на тему заката - более новая версия WordPress.
Скорее всего, вы скопировали WordPan Vanilla в свой SVN, измените его, работайте с ним.
Чтобы придерживаться примера с изображением, история будет содержать такие команды, как «скопировать всю картинку, добавить дерево, добавить листья».
Теперь вы приносите новую версию WordPress, так сказать новую картинку, и помещаете ее помимо вашей старой модифицированной версии. Проблема в том, что вы, люди и умники, знаете, что это во многом одна и та же картина, и, хотя новая версия отличается, вы просто должны скопировать дерево, но SVN не обладает такими знаниями. Для SVN ваша папка WordPress 1.7 (модифицированная) полностью отличается от WordPress 1.8. Они не разделяют историю, потому что ничто в журнале SVN не указывает на это. SVN - бюрократический сноб, не так ли? ;)
Теперь, что люди делают, чтобы svn поддерживал эту историческую связь между WordPress 1.7, вашим модифицированным 1.7 и новым 1.8 - они используют ветвление в самом начале своих работ.
Таким образом, вы начнете с чистой 1.7 wordpress в папке «vanilla-wordpress», сохраните ее в svn и разветвите, скажем, «my -ified-wp». Там вы будете взламывать, пока не почувствуете, что хотите обновить WordPress из апстрима Затем люди скачивают последнюю версию WordPress, перезаписывают свою ванильную WordPress и объединяют получившийся набор изменений.
На этом примере команды будут такими:
"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"
Вы можете точно воспроизвести закат, потому что знаете, как выглядела картинка до применения заката.
Ваша проблема, однако, в том, что вы не начали с этого момента, а сразу отредактировали загруженный WordPress. Таким образом, ваша новая копия WordPress не может быть легко связана с вашей измененной версией.
Один из способов установления исторических отношений
download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.
Теперь наступает хитрость
Прокрутите назад журнал SVN вашего "старого-модифицированного WordPress". Тот, который ты не разветвлял. Вы должны найти первую ревизию ПОСЛЕ первоначального импорта старого WordPress. Как только вы нашли эту ревизию, вы берете ее номер и используете его во второй из этих двух команд:
change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.
Вы говорите svn следующее: «Примите все изменения в моей старой ветке между версией 4 и СЕЙЧАС, и воспроизведите их на моей новой ветке».
Если все работает, у вас должно быть две одинаковые ветви. старый измененный и новый измененный с небольшим отличием, что у нового измененного есть солидная история с вашей веткой "/ vendor / wordpress / current".
Эта родословная позволяет вам непрерывно делать следующее:
Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit
Эту процедуру я опишу с меньшим количеством стористеллинга по ссылке. Но прежде чем он сможет работать, вы должны установить родословную связь между ветвями.
Subversion svn: переопределение внешних файлов?
Я знаю, что это было много, чтобы прочитать :). Если вы планируете рисовать соем, думайте о «командах изменения», а не о состояниях, и все будет в порядке.
C